




Add rule-based and 
object-oriented capabilities 
to C programs. Use the 
same compiler and 
debugger you're using now. 
RAL. An extension to 
the C language. Completely 
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SIMULATION BREAKTHROUGH 



SIMSCRIPT II.5 with SIMGRAPHICS 

Simulation models are now easier to build 
-results are easier to understand 


N ow you can provide the users 
of your SIMSCRIPT II.5 
models with SIMGRAPHICS™ 
-graphical input and animation. 

SIMSCRIPT II.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. 

With SIMGRAPHICS, results 
are easy to understand-animated 
pictures, histograms, pie charts and 
plots. 

Because your animated simula¬ 
tion results are easily understood, 
your recommendations are more 
likely to be acted upon. 

Free applications booklet 
A new booklet describing suc¬ 
cessful applications of SIMSCRIPT 
II.5® is now available. Typical ap¬ 
plications include: military plan¬ 
ning, manufacturing, communica¬ 
tions, logistics, and transportation. 

SIMSCRIPT II.5 is available on 
most popular computers including 
PC’s and Workstations. 


Free trial offer 

The free trial contains every¬ 
thing you need to try SIMSCRIPT 
II.5 on your computer. 

Try the SIMSCRIPT II.5 lan¬ 
guage, the built-in graphics, the 
quality and timeliness of our sup¬ 
port, and the accuracy of our 
documentation -everything you 
need for a successful project. 

For over 29 years CACI has 
provided trial use of its simulation 
software--no cost, no obligation. 
Act now—free training offer 

For a limited time we also in¬ 
clude free training. Call today to 
avoid disappointment-class size is 
limited. 


Rush information on 
SIMSCRIPT II.5 

□ Yes, I want to learn the reasons for the 
broad and growing popularity of SIM¬ 
SCRIPT II.5. Act now for free training. 

□ Send the free brochure “Major Applica¬ 
tions of SIMSCRIPT II.5.” 
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Computer Operating System 


□ Send details on your University Offer. 

Return to: IEEE COMP 

CACI Products Company 

3344 North Torrey Pines Court 

La Jolla, California 92037 

Call Eric Chapman at (619) 457-9681 

Fax (619) 457-1184 


For immediate information 

Call Doug Dittrich at (619) 
457-9681, or Fax (619) 457-1184. 
In Canada, call Peter Holt on 
(613) 782-2474, Fax (613) 
782-2202. In Europe, call Nigel 
McNamara, in the UK, on (081) 
332-0122, Fax (081) 332-0112. 


In Canada: 

CACI Products Division 
200-440 Laurier Avenue West 
Ottawa, Ontario KIR 7X6 

Call Peter Holt on (613) 782-2474 
Fax (613) 782-2202 
In Europe: 

CACI Products Division 
Palm Court, 4 Heron Square 
Richmond, Surrey TW9 1EW, UK 

Call Nigel McNamara on (081) 332-0122 
Fax (081) 332-0112 
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Brother can you spare 9 cents? 

Nine cents out of each dollar of the $21.3 million 
expected in revenues by the IEEE Computer Society this year. 

That’s how much comes from member fees. 


T he Computer Society’s Board of Governors and Execu¬ 
tive Committee have recently been looking very closely 
at the society’s finances, and have made observations 
both expected and surprising. This month I want to share some 
of those observations with you. The 1990 books are being 
closed as this is written, and Computer Society Treasurer 
Joseph Boykin will report the 1990 financial results formally 
and thoroughly in a subsequent issue of Computer. My com¬ 
ments this month are a relatively more informal look at some of 
our current projections for 1991, an overview of where the 
money comes from and where it goes. 

The Computer Society’s relative income from member fees is 
low for two reasons. First, a substantial portion of what mem¬ 
bers pay does not come to the society at all. (See Figure 1.) 
Society members who are also members of the IEEE are paying 
$85 this year, plus a regional assessment that ranges from $2 
(Region 10, Asia, and the Pacific Rim) to $20 (Regions 1-6, 
US). Of that $85, $63 goes to IEEE as the general member fee, 
entitling you to IEEE Spectrum, The Institute, and access to 
IEEE insurance and other programs. Only $22 comes to the 
Computer Society, the majority of which goes to pay for Com¬ 
puter. Affiliate members of the society, who are not members 
of IEEE and do not have access to IEEE publications and ser¬ 
vices, are paying a total of $54, of which $32 is taken by the 
IEEE as an affiliate fee, with only the remaining $22 constitut¬ 



Figure I. Composition of member fees. 


ing the society’s member fee. Thus, while the fees paid by 
members understandably look large, the majority of the fees 
paid, for both full and affiliate members, does not come to the 
society. 

The second reason this proportion is so low is that several of 
the society’s many successful programs not only support them¬ 
selves, but generate surpluses that can be used to support other 
essential society programs, some of which do not generate in¬ 
come and would otherwise have to be paid for out of the mem¬ 
ber fee income. 

The overall income structure of the society is displayed in 
Figure 2. The proportion of society revenues from member fees 
(9 percent) is very low. Other organizations of our type aver¬ 
age more than 30 percent, with many deriving well over half of 
their revenues from member fees and dues. Members do pay 
more than that, but for optional products and services of their 
choosing. For example, 12 percent of the society’s revenues 
come from optional member subscriptions to one or more of 
our 10 optional magazines and transactions. (On the average, 
nonstudent members of the society each subscribe to 1.4 op¬ 
tional periodicals.) Members also account for some of the sales 
(well under half — and at substantial member discounts) of CS 
Press products. Total press sales account for 18 percent of rev¬ 
enues. Advertising in society magazines generates 7 percent of 
our income. A very significant 19 percent comes from non- 
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Figure 2.1991 budgeted income structure. 
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member (library) subscriptions to our 11 periodicals. (That’s 
logical when you think about it, because no technical library 
worth the name can afford to be without the publications of the 
IEEE Computer Society, but still at rates considerably less than 
most commercial publishers.) 

The conferences and tutorials program generates 28 percent 
of total revenues, and includes not just conference registration 
fees but also optional tutorial fees and income from exhibits. 
(About half the attendees at a typical Computer Society confer¬ 
ence are members.) The remaining 7 percent of revenues come 
from a variety of sources, such as income on investments, rent, 
meetings fees for standards working groups, and other relative¬ 
ly small sources. 

This diversified revenue stream is one of the great strengths 
of your society. Especially critical is the way in which we are 
able to underwrite significant member programs with revenues 
generated by nonmember sales and subscriptions. We are oper¬ 
ated as a not-for-profit business, but we must also, necessarily, 
be not-for-loss. We must make enough surplus in those pro¬ 
gram areas where it is possible to do so to pay for the programs 
that generate no revenue, or at least not sufficient revenue to 
cover their full costs. In addition, as reported last year, the so¬ 
ciety’s Board of Governors has set us on a track to rebuild our 
reserves, seriously depleted in recent years, by formally adopt¬ 
ing budgets showing at least $750K surplus per year. While it 


currently looks as though we won’t make that full amount this 
year, we’re still on the right track. 

Figure 3 displays the 1991 surpluses currently projected for 
the three programs that generate surpluses: periodicals, confer¬ 
ences and tutorials, and the press. Income for the magazines 
and transactions is expected to exceed expenditures by $1.8 
million, even after funding subsidies for start-up and small-cir¬ 
culation titles. The press (nonperiodical publications including 
tutorial texts, monographs, and proceedings and video prod¬ 
ucts) is currently projected to have a surplus of just under one- 
half million dollars, and over fifty conferences that are spon¬ 
sored financially by the society are expected to generate a 
similar amount. Together these three program areas will bring 
in approximately $2.8 million more than they cost. 

What happens to that money? Some of it we invest in making 
our volunteers and staff more efficient. For example we now do 
most of our production publishing electronically, including 
electronic submission. We are studying ways to do our publica¬ 
tion distribution electronically as well. We are always evaluat¬ 
ing the possibilities of new publications and other products to 
keep up with new areas of member interest. These require in¬ 
vestment in the initial years until they can become self-suffi- 

As shown in Figure 4, we do lots of other good things as 
well. Our Technical Activities Board and technical committee 



Figure 3. Program surpluses. 


Figure 4. Support for other programs. 















SECOND CHAIR IN 
COMPUTER SCIENCE 

$A67 812 pa (Under Review) 

Reference No. 91242 X. Applications are invited 
for appointment to the second Chair in Computer 
Science, which has been established by the 
University as part of its commitment to a major 
expansion in the Discipline of Computer Science. 
The Chair is one of a number of academic positions 
being filled in the Discipline, which presently 
numbers 16 academic and technical staff. 

The University seeks applications from persons 
with an international reputation in core computer 
science and with the vision and commitment to 
develop a Discipline attuned to the challenges of 
fundamental developments in information science 
and technology. The University has a strong 
commitment to research and teaching excellence. 

The Discipline of Computer Science is part of 
the School of Information Science and Technology 
which also comprises the Disciplines of Mathematics 
and Statistical Science. In addition, a Joint Research 
Centre in Information Technology has been 
established between the University and the CSIRO, 
consisting of staff from both institutions. Professor 
JC Mudge has been appointed to the Foundation 
Chair of Computer Science, and is the Director of 
the Joint Research Centre. The second professor will 
be expected to serve as Head of the Discipline of 
Computer Science for at least an initial term of three 

The Discipline of Computer Science and the 
Joint Research Centre will be housed in a new 
$7 million building, to be completed in late 1991. 
Fibre-optics based internal communications, video- 
conferencing facilities, a tele-classroom, and links to 
external access wideband networks will be installed. 
From the outset the building will employ state-of- 
the-art communications technologies. With such an 
experimental facility, the University is equipped to 
take a leading research role in collaboration 
technology, image processing on broadband 
networks and communications environments. 

The University is located in the southern suburbs 
of Adelaide, a gracious and cultured city nestled 
between the hills and the beach which enjoys a 
mediterranean climate. Its performing arts complex 
is acclaimed as being one of the best in the world. 

The city has excellent restaurants and its nearby 
wine-growing areas produce two-thirds of Australia’s 
wine. Adelaide has a reputation for excellent 
housing at reasonable prices and for high quality 
education. 

Further information may be obtained from 
Professor Craig Mudge, telephone: 61-8-2012148, 
electronic mail: cschair@cs.flinders.oz.au. 

A salary loading may also be payable. The 
University encourages academic staff to undertake 
consulting and other professional activities relevant 
to their discipline. 

Written applications, quoting reference number, 
and giving full details of qualifications and 
experience and the names and addresses of at least 
three referees of whom confidential enquiries may 
be made, should be lodged with the Manager, 

Human Resources, The Flinders University of 
South Australia, GPO Box 2100, Adelaide SA 5001, 
by 31 May 1991. 

The University reserves the right not to make an 
appointment, or to appoint by invitation. 

Equal Employment Opportunity is University Policy 

FLINDERS 

UNIVERSITY 

ADELAIDE » AUSTRALIA 



programs, crucibles for the generation of many new pro¬ 
grams including both periodicals and conferences, will 
spend about $360K on newsletters and other projects. Al¬ 
most $300K goes to support standards activities (top-rated 
by the members in the last survey regarding program prior¬ 
ities). (As an aside, wherever possible we try to put pro¬ 
grams on a self-supporting basis. The standards program is 
a good example of this — as people become aware of its 
importance, they become willing to pay for it. Though the 
society will continue to underwrite the core support for the 
standards program, its expansion is being funded through 
registration fees, sales of draft standards, and other, similar 
means.) Programs in education, including curriculum 
projects and our participation in the Computing Sciences 
Accreditation Board (CSAB), account for $130K. 

A relatively modest $43K goes for the society’s awards 
program, which recognizes technical achievements and ser¬ 
vice to the society and the profession. A little over $700K 
is expended on membership activities, which include pro¬ 
motion, membership and application processing, the om¬ 
budsman, chapter activities and support, the Distinguished 
Visitors Program, and the Committee on Public Policy 
(COPP). The final $700K+ goes for a miscellany of ex¬ 
penses necessary to running this large “small business,” in¬ 
cluding expenses of the Board of Governors and officers, 
legal and audit fees, elections (we’ll spend $43K to con¬ 
duct the board and officer elections this year), fees and tax¬ 
es paid to IEEE, and consultant studies. (We’re doing a 
major survey of the membership again this year — the first 
since 1987 — to make sure our programs are in touch with 
what you want and need.) 

Serious, dedicated volunteer leaders, assisted by similar¬ 
ly dedicated professional staff, devote many hours to plan¬ 
ning and budget development each year. It’s always diffi¬ 
cult, because it just never seems possible to do everything. 
And we don’t have the luxury of being able to choose 
among good and bad ideas: We’re forced to choose be¬ 
tween good ideas and other good ideas. Through market 
surveys conducted before new periodicals are undertaken, 
and the member survey being conducted again this year, 
we try to make sure we keep in touch with the membership. 
That’s why a study recently published by ASAE, the pro¬ 
fessional society of executives of associations like ours, se¬ 
lected the IEEE Computer Society as one of 20 successful 
associations to illustrate the concept of market-driven man¬ 
agement in associations. 

We’re not perfect, but we’re trying hard. Let me hear 
from you if you like what we’re doing, or if you think we 
should do something different. I promise you that your 
leaders do listen. 


Duncan H. Lawrie 
Computer Society president 


COMPUTER 















IE USENIX SUMMER 1991 TECHNICAL CONFERENCE HDB 


MULTIMEDIA— FOR NOW AND THE FUTURE 


'«► What are the technical engineering requirements that will enable 
operating systems to support and deliver the new types of interfaces— 
voice, video, animated graphics, touch and music—that users are 
demanding now? 

»<* What must you, and your organization, do to meet the challenge of 
multimedia? 

■* How do we design new multimedia interfaces to improve information 
handling? Which projects, underway now, offer insight into the 
directions to be taken in developing fully integrated multimedia systems? 

These are some of the questions tackled by presenters and attendees at the 

USENIX Summer 1991 Technical Conference and Exhibition. 
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VARIETY OF FORUMS 


PLAN NOW TO ATTEND BDf! 


USENIX Summer 1991 Conference participants will explore general 
operating system and environment questions as well as address the 
conference theme: Multimedia— For Now And The Future. 


PEER-REVIEWED PAPERS 

Original work in operating systems and environments and discussion of the 
engineering requirements to support and deliver multimedia systems, particularly I 
experiences with integrating voice, video, audio, touch and music. 

TUTORIAL PROGRAM 

Hands-on tutorials by leading experts focus on multimedia, as well as additional 
topics essential to UNIX, UNIX-like and advanced computing systems and the 
C programming language such as: 

"♦Writing Applications with OPEN LOOK **TCP/IP Protocol Suite 
♦ Advanced Systems Administration Network Security 

««* Programming with X Toolkit Intrinsics Programming X Window 

«* Internals of UNIX System V Release 4.0 ♦ Using C++ Effectively 

PANEL DISCUSSIONS 

Protection of Software Intellectual Property, Window Systems and The Far- 
Reaching Possibilities of Location-Independent Computing are three of many 
topics of interest currently under review. 


USENIX SUMMER 1991 
TECHNICAL 
CONFERENCE 
& EXHIBITION 

June 10-14,1991 

Opryland Hotel ❖ Nashville, Tennessee 


OPRYLAND 


@□0 



MULTIMEDIA PRESENTATIONS 

State-of-the-art demonstrations of new, exciting 
work in multimedia on UNIX. 

INVITED PRESENTATIONS 

Potential topics include, among others: systems 
administration, software engineering techniques 
and security. 


8 USENIX 


the UNIX and Advanced Computing 
Systems Professional and Technical organization, is a 
not-for-profit association dedicated to 
"■* fostering innovation 

«* communicating technological developments, and 
sharing ideas and experience relevant to UNIX, 

UNIX- related and advanced computing systems 
providing a forum for the exercise of critical 
thought and airing of technical issues. 


Opryland Hotel 

Spacious facilities of the Opryland Hotel 
allow the entire program of technical sessions, 
tutorials, concurrent sessions and vendor 
exhibition to take place under one roof— 
a priority with USENIX conference 
and exhibition-goers. 
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TECHNICAL PROGRAM COMMITTEE 
Chair: Deborah K. Scherrer, mt Xinu 

Eric P. Allman, University of California, Berkeley 
Frances Brazier, Vrije Universiteit 
Tom Duff, AT&T Bell Laboratories 
Daniel E. Geer, Digital Equipment Corp. 

Stanley P. Hanks, Baylor College of Medicine 
Michael Hawley, MIT Media Laboratory 
Jun Murai, Keio University 
Alan G. Nemeth, Digital Equipment Corp. 

Jeff Peck, Sun Microsystems 
Charles E. Perkins, IBM TJ. Watson Research Ctr. 
Gretchen Phillips, SUNY Buffalo 
Charles S. Roberts, Hewlett-Packard 
Larry Stead, Bellcore 
Avadis Tevanian, NeXT, Inc. 
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MORE CONFERENCE 
INFORMATION 

Please contact: 

USENIX Conference Office 
(714)588-8649 
FAX (714) 588-9706 
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UNIX is a registered Trademark of UNIX System Laboratories 



















































Addendum to March article 


Eye monitor: Examples of 
eye movements recorded 
by computer-based 
“smart” instrument 

An important figure was omitted in 
Computer 's March 1991 publication of 
“Eye Monitor: Microcomputer-Based In¬ 
strument Uses an Internal Model to 
Track the Eye” by Glenn A. Myers, 

Keith R. Sherman, and Lawrence Stark 
(pp. 14-21). The figure, as it should have 
appeared on p. 18, is reproduced at right. 

The authors used an internal model of 
the eye to greatly improve the ability of a 
video-based image-processing system to 
accurately measure eye movements and 
pupillary changes in spite of interfering 
noise from eyelashes and blurring due to 
subject motion or intervening lenses. The 
system uses the shape, size, position, and 
darkness of the pupil to ensure accurate 
and robust measurements. 

Computer regrets the error and any 
embarrassment or confusion it may have 
caused the authors or our readers. 


Pursuit Saccades Reading/Scanpaths Reading Reading 



reading eye movements, showing the horizontal (rightmost panel) and vertical 
eye movements. The middle panel shows eye movements (with time implicit) of a 
subject reading Chinese.* The two panels at the left display saccadic and 
smooth-pursuit eye movements as a function of time. 

*Adapted from F. Sun, M. Morita, and L. Stark, “Comparative Patterns of Reading 
Eye Movements in Chinese and English,” Perception and Psychophysics, Vol. 37, 
May 1985, pp. 502-506. 


Scientists 

Panasonic Information Technology Laboratory 
Princeton, N J. 

Panasonic Technologies, Inc. has established a new computer 
science research laboratory in Princeton, N.J. The primary focus of the 
Information Technology Laboratory (ITL) will be fundamental 
computer systems research, including (but not limited to) high 
performance computer architectures, distributed systems, database 
management systems, and real-time computer graphics. The 
laboratory is located in downtown Princeton, next to Princeton 
University. 

Positions are available at all levels for highly qualified individuals. 
Ph.D. or equivalent and proven research record required for Senior 
Scientist position; Ph.D. or equivalent required for Scientist position; 
Master or Bachelor degrees required for other research positions; 
extensive technical or programming experience for laboratory or 
programming positions. 

Please send resume to: Dr. Richard Lipton, Panasonic 
Information Technology Laboratory, P.O. Box 3289, Princeton, 
N.J. 08543-3289. Panasonic Technologies, Inc. is an Equal 
Opportunity Employer M/F. 


Panasonic 
Technologies, Inc. 


AAA 


a i 


THE NATIONAL 
CONFERENCE ON 
ARTIFICIAL 
INTELLIGENCE 
& 

INNOVATIVE 
APPLICATIONS 
OF ARTIFICIAL 
INTELLIGENCE 
CONFERENCE 


JULY 14-19,1991 
ANAHEIM, CA 


A unique combination brings together both 
scientific and business communities in the 
year’s leading AI forum. . .technical 
programs, tutorials, applications, interactive 
solution-focused panels. . . plus exhibits/ 
demonstrations by leading suppliers of AI 
hardware, software and services. 


American Association for 
Artificial Intelligence 
445 Burgess Drive, Menlo Park, CA 94025 
Phone 415-328-3123, fax 415-321-4457 


i a a i - a i 






































Open „nd closed 

case 


Searching for the right CASE partner for your organization? 
Once you know what to look for, finding the right partner is 
elementary. All the evidence points to IDE. Its success formula 
combines the right CASE process, tools, training and support 
to make you successful. 

To implement your CASE strategy, start with UNIX— 
the proven choice of software developers. UNIX 
provides the best foundation for multi-user envi¬ 
ronments and offers the widest array of modern 
development tools. Most illuminating. 

Add IDE’s Software through Pictures® and 
your choice of other best-of-class tools such 
as Saber-C, FrameMaker and Interleaf. Software 
through Pictures integrates all these tools with a 
shared repository, supports structured and object- 
oriented methods, and runs over heterogeneous networks 
of Sun, Digital, HP and IBM workstations and X terminals. 

Closed products from other vendors fell far short of IDE’s open 
strategy. Why settle for a 7% solution when you can have it all? 

Look closely at your CASE alternatives and you’ll see why IDE 
is the obvious choice. Only IDE offers you open and extensible 
solutions such as the C Development Environment™ that guarantee 
you can refine your CASE strategies to meet future requirements. 
And if you’re just getting started with CASE, IDE’s Pilot Project 
Package provides all the software, training and support you 
need to make your first project a brilliant success. 

Fortuitous indeed. 

To learn how to create a successful CASE 
strategy for your organization, come to an 
IDE seminar. Or call us for more infor¬ 
mation. We’ll be happy to provide you 
with all the proof you need. 

For more information or to 
register for an IDE seminar in 
your area, call 
1-800-888-IDE1 Ext 919 
1-415-543-0900 Ext. 919 
E-mail address: sherlock@ide.com 
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Guest Editors’ Introduction 



Real-Time Systems 


C.M. Krishna, University of Massachusetts 
Y.H. Lee, University of Florida 


H umans make poor controllers. We 
are slow to react to external events, 
possess limited capacity for pro¬ 
cessing information, and are prone to fa¬ 
tigue. 

None of this matters when controlled 
processes are simple. For example, tradi¬ 
tional aircraft travel several hundred miles 
per hour but require just a few control 
adjustments per minute. Times are chang¬ 
ing, however, and applications are emerg¬ 
ing that humans cannot adequately control. 
Already, “fly-by-wire” aircraft exist that 
feature fully electronic cockpits, with no 
mechanical backups, and computer-con¬ 
trolled actuators. Future aircraft will prob¬ 
ably be inherently unstable to achieve 
greater fuel efficiency. Because of their 
speed, computers will be needed to control 
such aircraft: Unlike us, computers can 
react quickly to correct instability before it 
snowballs into uncontrollability. 

The first formal studies of humans as 
controllers focused on the responses of 
World War II antiaircraft gunners and ra¬ 
dar operators. From these studies, our lim¬ 


itations became apparent, which led to 
“aided tracking” techniques for human 
operators. These techniques added infor¬ 
mation to a display (subject to the limits on 
a person’s ability to process information) 
and synthesized control signals that in¬ 
cluded the derivatives of the operator’s 
commands. However, the techniques are 
of limited utility because of the above- 
mentioned limits on human ability. 

The development of computer technolo¬ 
gy has revolutionized the control of com¬ 
plex processes. Computers compensate for 
limits on our information-processing abil¬ 
ity by displaying only those data that are 
currently important. They can compensate 
for limits on our reaction speed by limiting 
the operator functions to policy formula¬ 
tion and by taking over the job of imple¬ 
mentation. Computer availability thus al¬ 
lows us to indirectly control processes that 
would otherwise be beyond our abilities. 

By using computers in these critical roles, 
we become hostages to their good perfor¬ 
mance. For example, if the computer in a 
fly-by-wire aircraft crashes, so does the 


aircraft. If a computer in an automobile 
antilock braking system crashes, the car 
can go out of control. Therefore, we must 
design such systems to be highly reliable. 
They must be sufficiently fault-tolerant to 
withstand losing large portions of the hard¬ 
ware or the software and still perform critical 
functions. 

This requirement is complicated by the 
fact that real-time systems can fail not only 
because of massive hardware or software 
failure, but also because the system is un¬ 
able to execute its critical workload in 
time. The computer is in the feedback loop 
corresponds to delays in the feedback loop. 
These delays can degrade the quality of 
control or even cause the controlled pro¬ 
cess to go out control. 

These performance and reliability re¬ 
quirements raise formidable specification 
and design problems. Also, the performance/ 
reliability of such systems must be formal¬ 
ly validated by the appropriate certifica¬ 
tion authorities (for example, the Federal 
Aviation Administration). 

Formal specification techniques are im¬ 
portant because they encapsulate the needs 
of the controlled process in a form that is 
intelligible to the computer designer. In 
effect, they form an interface between the 
control engineer and the computer design¬ 
er. Erroneous or incomplete specifications 
can prove very expensive. Unfortunately, 
the state of the art in this area is rather 
primitive. 

The standard method of designing a re¬ 
liable real-time system uses two kinds of 
redundancy: space and time. Spatial re¬ 
dundancy uses additional hardware or soft¬ 
ware. For example, you might have three 
processors instead of one, and vote on their 
results, choosing the majority output as the 
correct one. This allows for masking one 
failure. You might also use multi version 
programming: Run in parallel several in- 


Further reading 

A useful starting point for readers unfamiliar with this field is the article by Stankovic. 1 
There is no text on real-time computing that adequately covers the entire field, but the best 
single reference is Hard Real-Time Systems , z which is an excellent collection of papers. 

The August 1987 edition of the IEEE Transactions on Computers featured a special issue 
on real-time systems. The July 1989 edition of the ACM Operating Systems Review dealt ex¬ 
clusively with real-time operating systems. Articles on real-time computing appear frequently 
in the IEEE Transactions on Computers, IEEE Transactions on Software Engineering, and the 
Journal of Real-Time Systems (Kluwer, Inc.). 

The principal conference is the annual IEEE Real-Time Systems Symposium, which was 
initiated in 1980 and is held every December. Other annual conferences that have featured 
real-time papers include the IEEE Fault-Tolerant Computing Symposium, the IEEE Interna¬ 
tional Conference on Distributed Computing Systems, the IEEE Reliable Distributed Systems 
Conference, and the Real-Time Programming workshops sponsored by the International Fed¬ 
eration of Automatic Control. 

1. J.A. Stankovic, “Misconceptions about Real-Time Computing," Computer, Oct. 1988, pp. 10-19. 

2. J.A. Stankovic and K. Ramamritham, Hard Real-Time Systems, CS Press, Los Alamitos, Calif., 1984. 
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dependently written programs, and vote on 
the results. Error-control coding is frequently 
used to detect and correct memory errors. 

For spatial redundancy to improve reli¬ 
ability, the failures must be independent. 
Spatial redundancy cannot help when fail¬ 
ures are correlated, such as when multiple 
units fail simultaneously or within a short 
time of one another. For example, if three 
processors are powered by the same sup¬ 
ply, all three will crash simultaneously if 
the power supply fails. Careful design is 
needed to reduce the incidence of correlat¬ 
ed failures. 

In the second form of redundancy, time, 
most failures are not permanent but tran¬ 
sient. The operating environment causes 
many of them. That is, an environmental 
upset — such as electromagnetic radiation 
or a beam of charged particles — can tem¬ 
porarily affect the computer, either partial¬ 
ly or wholly. After the disturbance passes, 
the system can continue functioning. Be¬ 
cause the entire system is subject to the 
same environmental upset, the incidence of 
correlated transient failures could be sig¬ 
nificant. To defeat such events, there must 
be adequate slack time for the system to 
deliver timely output even after suffering a 
transient failure. 

Because of the timing constraints, the 
algorithm that schedules tasks on proces¬ 
sors impacts system reliability. Therefore, 
task scheduling is a matter of both reliabil¬ 
ity and performance. The more predictable 
the task runtimes, the easier the scheduling. 

Validation is perhaps even more difficult 
than design. To begin with, the overall 
system should be so reliable that standard 
statistical approaches to calculating reli¬ 
ability are impractical. For example, NASA 
has suggested that computers used in civil¬ 
ian fly-by-wire aircraft have a failure prob¬ 
ability of no more than 10“ 9 per hour. It would 
take millennia to obtain good failure prob¬ 
ability data by running prototypes that satisfy 
that requirement. As a result, performance 
models are needed to predict system per¬ 
formance as a function of parameters that 
can be measured experimentally. These 
parameters might include the failure rate of 
individual processors, buses, and software 
modules. 

Finally, the performance of real-time 
machines must be expressed through mea¬ 
sures that are meaningful to the applica¬ 
tion. Traditional measures such as reliabil¬ 
ity and throughput are not precise enough 
to do this, and other measures are needed. 
One good example is performability, which 
combines attributes of reliability and per¬ 
formance in the context of the application. 


Real-time computing promises to be a 
fruitful source of technical problems and 
challenges for many years to come. Many 
problems in this field are the same as those 
in the fault-tolerant and general-purpose 
computing fields. However, because hard 
task deadlines exist, the answers to these 
problems are frequently different. 

A few examples will illustrate this point. 
We know little about formally specifying 
real-time systems to adequately convey the 
needs of the controlled process to the com¬ 
puter designer (who frequently knows 
nothing about control theory). We know 
even less about predicting program runt¬ 
imes. We have elaborate models of system 
reliability, but we know almost nothing 
about modeling design errors in a field 
where timing plays an important role. 

Finally, there is the matter of cost. De¬ 
signers who put computers in control of 
aircraft have the luxury of deploying mas¬ 
sive redundancy. However, as real-time 
computers become common in more 
mundane applications, the cost of the com¬ 
puter hardware becomes an important 
concern. A good example is the automo¬ 
bile. All the technical constraints of a harsh 
operating environment and critical work¬ 
loads that exist in aerospace computing 
also exist in computerized automobile 
control (that is, collision avoidance, brak¬ 
ing control, etc.). However, car sales can 
be seriously affected by just a few hundred 
dollars increase in price. The challenge to 
make real-time computing affordable is 
perhaps the most difficult of all. 


T his issue of Computer contains ar¬ 
ticles that introduce the rapidly 
growing field of real-time comput¬ 
ing. The following pages contain articles 
on specification, design, and performance 
evaluation and the sidebar will provide 
some leads for further reading. 

We hope this special issue stimulates 
more readers to conduct research in this 
field. It is relatively new, even by the 
standards of computer engineering. As a 
result, there are many important problems 
in specification, design, validation, task 
scheduling, and quick fault recovery that 
must be solved. As we mentioned before, 
almost every research problem in fault- 
tolerant computing is also a problem in 
real-time computing. However, because of 
the deadlines that characterize real-time 
systems, the solutions to these problems in 
real-time computing are frequently more 
challenging. ■ 
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A Design Approach 
for Ultrareliable 
Real-Time Systems 


Jaynarayan H. Lala, Richard E. Harper, and Linda S. Alger 
Charles Stark Draper Laboratory 


U ltrareliable real-time computing 
became an important issue at the 
Charles Stark Draper Laboratory 
when designers began to incorporate digi¬ 
tal computers into guidance, navigation, 
and control systems. Although we had been 
designing these systems for missiles and 
spacecraft for 30 years, we began to focus 
on a class of applications characterized by 
an unusually stringent set of reliability and 
real-time performance requirements. Hence, 
we coined the term ultrareliable real-time 
systems for these applications. 

Real-time information processing is in¬ 
trinsic to the operation of all these systems. 
Early systems emphasized fault avoidance 
through rigorous quality control and com¬ 
ponent engineering to enhance reliability. 
This approach proved quite satisfactory 
for the US Navy’s fleet ballistic missile 
series of Polaris, Poseidon, Trident I, and 
Trident II, and for the guidance and navi¬ 
gation computer on board the Apollo expe¬ 
ditions to the moon. 

There was a cost penalty, however, for 
engineering high reliability into devices 
through a reduced component failure rate. 


Managing redundancy 
is vital to the correct 
operation of critical 
systems. We present 
several approaches to 
masking errors and 
achieving congruency 
in the presence of 
a fault. 


With the advent of the microprocessor, the 
weight, volume, and power associated with 
redundant hardware decreased. (These 
physical resources, of course, are always at 
a premium in aerospace vehicles.) The mi¬ 


croprocessor made it possible to trade off 
fault-tolerance and fault-avoidance tech¬ 
niques to minimize the overall cost. 

Redundancy-based architectures de¬ 
signed in the early 1970s included duplex 
and triplex systems. Reconfigurable archi¬ 
tectures evolved later, culminating in the 
late 1970s in Draper’s Fault-Tolerant Mul¬ 
tiprocessor (FTMP), which uses parallel- 
hybrid redundancy. Hopkins, Lala, and. 
Smith summarize a selected set of Draper- 
developed ultrareliable computers from the 
Apollo Guidance Computer to the FTMP. 1 

Experience with these early systems 
showed that redundancy can provide a cost- 
effective alternative to fault avoidance. 
However, redundancy also substantially 
complicated the task of validation. In fact, 
it was all too easy to end up with a redun¬ 
dant system that was more failure prone 
than a simplex system. 

Correct management of redundancy is 
essential to making a redundant system 
fault tolerant. The complexity of the vali¬ 
dation of fault-tolerant systems relates di¬ 
rectly to the approach taken to manage 
their redundancy. Fault propagation, error 
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propagation, synchronization of and con¬ 
sensus between redundant elements, and 
other redundancy management issues had 
to be based on a solid theoretical founda¬ 
tion if designers had any hope of formally 
validating these systems. 

In this article, we describe the design 
approach evolved at Draper over the past 
few years to formalize redundancy man¬ 
agement and validation. We developed 
several architectures with this approach. 
We discuss the Advanced Information 
Processing System (AIPS), which is a fault- 
tolerant distributed architecture, and con¬ 
clude with a brief overview of recent appli¬ 
cations of these systems and our current 
research. 

Requirements and 
design approach 

Fault-tolerant computers are now used 
in a diverse set of applications, and the 
techniques for achieving fault tolerance 
vary as much as the application require¬ 
ments. We focus here on achieving fault 
tolerance for ultrareliable real-time sys¬ 
tems. 

One way to define reliability require¬ 
ments for these systems and to distinguish 
them from other fault-tolerant applications 
is to measure them in terms of a maximum 
acceptable probability of failure. Because 
of the total dependence of the application 
on the correct operation of the system, the 
acceptable probability of failure of the 
computer is very small, typically in the 
range of 10~ 5 to 10 -10 , depending on the 
consequences of the failure. Safety-critical 
applications are the most demanding. 
Commercial transport fly-by-wire, such as 
the Airbus A-320, require a 10 -10 probability 
of failure per flight hour. (In this type of 
flight control, a computer processes all 
pilot commands. There is no direct me¬ 
chanical link between the pilot control wheel 
and the control-surface actuators.) 

Similar applications in military aircraft 
are several orders of magnitude less de¬ 
manding, typically around 10~ 7 per hour 
(presumably because the crew can bail 
out). Vehicle-critical applications in which 
the cost of failure is a huge economic 
penalty rather than loss of life (such as 
unmanned launch vehicles, autonomous 
underwater vehicles, and full-authority 
engine controls) require 10“ 6 to 10“ 7 prob¬ 
abilities of failure per hour. 

Mission-critical applications in which a 
computer failure would cause an incom¬ 
plete or aborted mission occupy the low 


end of the ultrareliable spectrum. Typical 
reliability requirements are 10' 4 to 10“ 6 
probabilities of mission failure. 

The real-time response requirements for 
the applications under consideration are 
also very demanding. For example, stati¬ 
cally unstable fighter aircraft can develop 
divergent flight modes if correct control 
inputs are not applied every 40 to 100 
milliseconds. Similarly, advanced variable- 
cycle jet engines can blow up if correct 
control inputs are not applied every 20 to 
50 milliseconds. Mission-critical functions 
do not have such stringent response-time 
requirements but typically need higher 
throughput. 

A third requirement, although no one 
ever states it explicitly, is system capabil¬ 
ity for validation. Commercial fly-by-wire 
systems cannot be placed into service in 
the US until the Federal Aviation Admin¬ 
istration is satisfied with their safety. 
Similarly, the Nuclear Regulatory Com¬ 
mission must certify nuclear power-plant 
trip monitors and controls, the National 
Aeronautics and Space Administration must 
certify the avionics used on board space¬ 
craft, and so on. 

Because of the extremely low failure 
rate required of these systems, life-time 
testing for the purposes of certification is 
out of the question. Although empirical 
data collected on test articles in the labora¬ 
tory and/or flight systems can be used as 
part of the validation process, the primary 
means is a hierarchy of analytical models, 
simulations, and proofs that would satisfy 
any determined inquisitor that a system 
can perform its intended function correctly 
under all expected conditions. 


Draper design philosophy. We have 
evolved a philosophy to address the unique 
requirements of ultrareliable real-time 
systems based on a number of major pre¬ 
cepts. 

Hardware redundancy protects against 
random hardware faults (also known as 
operational faults). Due to the stringent 
real-time requirements discussed earlier, 
application functions cannot be suspended 
for more than a few milliseconds when a 
component fails. Fault effects must be 
masked until recovery measures can be 
taken. A majority voting architecture with 
a triplex-or-higher level of redundancy 
masks errors and provides spares to re¬ 
store error masking after a failure. Use of 
redundancy, of course, is quite common in 
critical systems. However, managing that 
redundancy is supremely important. 


Redundancy alone does not guarantee 
fault tolerance. The only thing it does guar¬ 
antee is a higher fault arrival rate compared 
to a nonredundant system of the same 
functionality. For a redundant system to 
continue correct operation in the presence 
of a fault, the redundancy must be managed 
properly. Redundancy management issues 
are deeply interrelated and determine not 
only the ultimate system reliability but 
also the performance penalty paid for fault 
tolerance. Some fault-tolerant computers 
end up spending as much as 50 percent of 
their throughput managing redundancy. 2 

As a first step in addressing this issue, 
we partitioned the redundant elements into 
individual fault containment regions. An 
FCR is a collection of components that 
operates correctly regardless of any arbi¬ 
trary logical or electrical fault outside the 
region. Conversely, a fault in an FCR cannot 
cause hardware outside the region to fail. 

To form a fault containment boundary 
around a collection of hardware compo¬ 
nents, one must provide that hardware with 
independent power and clocking sources. 
Additionally, interfaces between FCRs must 
be electrically isolated. The isolation should 
be robust enough to tolerate a short to the 
maximum voltage available in the FCR. 
Depending on the application, this may be 
5 V or 28 V DC, 115 V AC — or even higher 
in a HERF/EMI (high-energy radio fre¬ 
quency/electromagnetic interference) en¬ 
vironment. 

Some applications also require toler¬ 
ance to such physical damage as a weapons 
hit or flooding. In those cases, FCRs must 
also be physically separated, typically done 
by locating redundant elements in different 
avionics bays on aircraft or in compart¬ 
ments separated by bulkheads in underwater 
vehicles. 

Due to all these requirements, it is im¬ 
practical to make each semiconductor chip, 
or even a board, an FCR. A realistic FCR 
size is that of a whole computer, also called 
a channel in the avionics parlance. A typi¬ 
cal channel contains a processor, memory, 
I/O interfaces, and data and control inter¬ 
faces to other channels. If the FCR require¬ 
ments are enforced rigorously, one can 
argue that random hardware component 
failures in FCRs constitute independent 
and uncorrelated events. This is an impor¬ 
tant underpinning of the analytical models 
used to predict the probability of failure of 
these systems. 

Although an FCR can keep a fault from 
propagating to other FCRs, fault effects 
manifested as erroneous data can propa¬ 
gate across FCR boundaries. Therefore, 
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the system must provide error contain¬ 
ment. The basic principle is fairly straight¬ 
forward: “Voting planes” mask errors at 
different stages in a fault-tolerant system. 
For example, a typical embedded control 
application involves three steps: read re¬ 
dundant sensors, perform control law 
computation, and output actuator com¬ 
mands. 

In this embedded application, an input 
voting plane masks failed sensor values to 
keep them from propagating to the control 
law. Internal computer voting masks erro¬ 
neous data from a failed channel to prevent 
propagation to other channels. Output vot¬ 
ing and an interlock mechanism prevent 
outputs of failed channels from propagat¬ 
ing outside the computational core. 

The interlock is a hardware device in 
each channel that can enable or disable the 
outputs of that channel. Only a majority of 
the channels can change the interlock state. 
Therefore, in triplex or higher redundancy 
level computers, the majority of channels 
can disable the outputs of a failed channel. 

Finally, a voting plane at the actuator 
masks errors in the transmission medium 
that connects the computer to the actua¬ 
tors. The typical actuator is driven by 
multiple electrical or hydraulic inputs so 
that a majority of inputs can drive it to the 
correct position even when one of the in¬ 
puts fails to its maximum value, or a 
“hardover failure.” 

Masking faults and errors obviates the 
need for immediate diagnostics, isolation, 
and reconfiguration. The application func¬ 
tions need not be suspended. The majority 
of channels can continue to execute these 
functions correctly and provide correct 
outputs. This approach meets the stringent 
real-time response requirements. 

Exact versus approximate consensus. 

To mask errors, outputs of redundant chan¬ 
nels must be compared and voted. Two 
distinct voter approaches have evolved to 
provide these functions. These methods 
affect everything from efficiency of fault 
tolerance to coverage of faults to valida¬ 
tion of hardware and software. 

The two approaches seem to affect only 
the voter at first glance, but they actually 
go to the heart of the architecture. Draper 
favors an architectural approach that re¬ 
quires the outputs of all channels to agree 
bit-for-bit under no-fault conditions. This 
exact bit-wise consensus is used in most 
fault-tolerant computers (such as the Space 
Shuttle; Software-Implemented Fault Tol¬ 
erance, or SIFT; Tandem; Stratus; X-29 
Flight Control System; and Biin). 


In contrast, a few others (such as AFTI/ 
F-16 Flight Control System and Sperry/ 
B-737 Yaw Damper) use the approximate 
consensus approach in which the outputs 
of redundant channels agree within some 
threshold (also called a window of agree¬ 
ment) under no-fault conditions. 

The use of the exact consensus approach 
can best be motivated and discussed by 
addressing the limitations of approximate 
consensus. Fault-detection coverage in the 
latter approach is a function of how pre¬ 
cisely one defines the thresholds. 

For most dynamic systems, thresholds 
are a function of the process and its inputs 
and outputs. Thresholds may also change 
with the operating mode. For example, the 
outputs of a redundant flight-control com¬ 
puter can be expected to be very close in a 
level, cruising flight with control-law in¬ 
puts relatively constant. However, in a high¬ 
speed maneuver in which aircraft altitude, 
velocity, and other inputs change very rap¬ 
idly, the outputs of redundant channels can 
be much farther apart. 

Since there is no mathematically precise 
way to define these thresholds, most de¬ 
signers use heuristics guided by two op¬ 
posing requirements. Making the thresh¬ 
old or window of agreement too small 
generates nuisance false alarms. Making 
the window too wide to avoid false alarms 
will miss some real faults and lower fault- 
detection coverage. Due to this dilemma, 
fault-detection coverage in approximate 
consensus systems cannot approach 100 
percent. In fact, there is no formal method¬ 
ology for accurately calculating the cover¬ 
age achieved for a given threshold size. 
This makes analytical modeling and vali¬ 
dation extremely tedious, if not impossi¬ 
ble. Furthermore, the use of application- 
process-derived thresholds for fault 
detection and isolation puts a serious and 
uncalled-for burden on the applications 
programmer to assure fault tolerance in the 
host machine. 

Consider another limitation of the ap¬ 
proximate consensus approach. A distrib¬ 
uted network of redundant computers could 
only exchange and vote interprocessor 
messages that consisted of physical quan¬ 
tities. Most of the communication traffic in 
a distributed system typically has no phys¬ 
ical semantics. The notion of approximate 
equality between redundant copies of such 
abstract messages is meaningless. The 
concepts of approximately near or far apart, 
in fact, are meaningless for most variables 
in a computer. 

The exact consensus approach, in con¬ 
trast, rests on a foundation of clearly de¬ 


fined requirements and is amenable to 
formal methods and analytical validation. 
It begins with the realization that digital 
computers are finite-state machines. Under 
the following well-defined conditions, re¬ 
dundant digital computers produce bit-for- 
bit identical results. 

Identical initial states. The redundant 
copies of the hardware must be initialized 
to the same state. For a typical channel, this 
implies that at some initial time all vol¬ 
atile memory, processor cache and regis¬ 
ters, control registers, and clock and counter 
values (including the states of intermediate 
stages, discretes, etc.) are identical in all 
copies. 

Identical inputs. Each hardware copy 
must then be provided with an identical 
sequence of inputs. In real-time systems, 
typical inputs include data (such as sensor 
values) and events (such as interrupts gen¬ 
erated within a channel or asserted by an 
external device). The interfacing of sen¬ 
sors (simplex and redundant) to redundant 
channels and correct distribution of sensor 
values to all channels is a very important 
aspect of ultrareliable real-time architec¬ 
tures. Interrupts must be asserted in each 
channel at identical points in the instruction 
stream. 

Identical operations. Each channel must 
execute the same sequence of operations 
on the same inputs. 

Bounded time skew. An upper bound on 
the time skew At skew must be defined so that 
the time of completion for a given se¬ 
quence of instructions for the slowest 
channel, t s , is no larger than the time for the 
fastest channel, t f . by more than Ar skew . The 
time skew is bounded by synchronizing the 
operations of redundant channels. 

If all these requirements are satisfied, 
then each nonfaulty channel will produce 
bit-for-bit identical outputs by a well- 
defined point in time. 

Synchronization, input agreement, 
and input validity conditions. T wo or more 
identically initiated processes that receive 
identical inputs and operate on them the 
same way are called congruent processes. 
Congruence, unlike threshold-based ap¬ 
proaches, allows a mathematically precise 
and concise means for detecting and isolat¬ 
ing faults: 

• Fault detection. Two congruent pro¬ 
cesses that do not agree bit-wise produce 
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an error condition, which indicates the 
presence of a fault. 

• Fault isolation. A congruent process 
that does not agree bit-wise with the major¬ 
ity of congruent processes is faulty. Note 
that the majority vote for congruent systems 
is a simple truth table. 


Synchronization. Synchronizing redun¬ 
dant channels places an upper bound on the 
time skew. Since the workload typically 
consists of iterative execution of various 
application programs at different frequen¬ 
cies, a commonly used technique synchro¬ 
nizes the start of the next frame by having 
the redundant processes exchange sema¬ 
phores at the end of an iteration. 

Two major problems with this approach 
are the high software overhead for syn¬ 
chronization and the additional burden on 
the applications programmer to perform 
the synchronization task. Because of mul¬ 
tiple frame rates and passing of I/O data 
between various frames, the high cognitive 
overhead of maintaining synchronism falls 
to the applications programmer. This 
worsens in the presence of faults, compli¬ 
cating the task of validating applications 
software. 

An alternative approach developed at 
Draper uses a hardware-implemented syn¬ 
chronization scheme transparent to appli¬ 
cations software. This approach relies on 
identical redundant hardware clocked by a 
fault-tolerant clock. The copies of hardware 
execute a given instruction in an identical 
number of CPU clock cycles. The fault- 
tolerant clock source provides exactly the 
same number of CPU clock ticks in a given 
time period to each redundant copy of the 
hardware. 

The fault-tolerant clock, as the name 
implies, is not a single clocking source but 
is independently derived in each channel 
by a majority vote of a redundant set of 
clocks. We used this hardware synchroni¬ 
zation scheme in the Advanced Informa¬ 
tion Processing System (AIPS) fault-toler¬ 
ant processor by making all hardware 
clock-deterministic. The clock determin¬ 
ism attribute can be imparted to digital 
hardware through appropriate design rules 
and makes the execution time of each in¬ 
struction, as measured in the number of 
CPU clock cycles, a fixed and determinis¬ 
tic number. 

Input agreement. Correct distribution of 
inputs (in general) and sensors (in particu¬ 
lar) is a very important aspect of ultrareli¬ 
able real-time architectures. Incorrect dis¬ 


The Byzantine Generals’ Problem 


The analogy between fault-tolerant systems and Byzantine generals originates 
in the famous paper by Lamport, Shostak, and Pease 4 : 

Reliable computer systems must handle malfunctioning components that give conflicting 
information to different parts of the system. The situation can be expressed abstractly in 
terms of a group of generals of the Byzantine army camped with their troops around an 
enemy city. Communicating only by messenger, the generals must agree upon a 
common battle plan. However, one or more of them may be traitors who will try to confuse 
the others. The problem is to find an algorithm to ensure that the loyal generals will reach 
an agreement. 

The generals in this analogy correspond to processors in a redundant comput¬ 
ing system, the traitors correspond to faulty processors, and the messengers 
correspond to interprocessor communications links. It is typically assumed that 
faulty-link (traitorous messenger) behavior is subsumed by faulty-source proces¬ 
sor (traitorous general) behavior. 


tribution has caused at least one in-flight 
failure of a redundant computer. 3 

There are two conditions attached to 
inputs: congruency (or agreement) and 
validity. Input congruency occurs when 
each channel has an identical copy of that 
input, that is, all channels agree on the 
input value. Input validity occurs when all 
channels have a valid or correct value of 
that input. 

Note that congruency does not imply 
validity. All channels may have the same 
wrong value, for example, and still be in 
agreement. Input congruency is the only 
necessary condition for bit-wise output 
consensus. Validity is necessary for cor¬ 
rect channel outputs. 

A recent theory, sometimes referred to 
as the Byzantine Generals’ Problem, iden¬ 
tifies the necessary conditions for input 
congruency in the presence of an arbitrary 
fault (see sidebar). According to this the¬ 
ory, 4-7 to achieve input source congruency 
in the presence of/arbitrary, or Byzantine, 
faults 

(1) the system must consist of 3/ + 1 
FCRs, 

(2) the FCRs must be interconnected 
through 2/+ 1 disjoint paths, 

(3) the inputs must be exchanged/-!- 1 
times between the participants, and 

(4) the FCRs must be synchronized to 
provide a bounded skew. 

The 3/+ 1 rule was actually discovered 
at Draper in 1973 — but only in the limited 
context of designing fault-tolerant clocks. 8 
We had observed malicious clock failures 
and concluded that 3/+ 1 — rather than the 


simple majority voting scheme that uses 
2/ + 1 clocks — is required to design a 
fault-tolerant clock. We did not, however, 
realize that data communication can also 
display Byzantine behavior. 

A redundant system that can achieve 
exact consensus in the presence of one 
arbitrary fault must have at least four fully 
cross-strapped FCRs that execute a two- 
round exchange algorithm to distribute in¬ 
puts. Note that the most commonly found 
triple-redundant majority-voting architec¬ 
tures do not meet these requirements. 

A number of single-point failures can be 
postulated that would cause the inputs to 
be noncongruent in the three channels, 
leading to a total system failure. Can such 
failures occur? A commonly observed 
Byzantine failure occurs when a marginal 
bus transmitter causes two receivers to 
perceive different values for a transmis¬ 
sion. The question is not whether such 
failures can occur but how probable they 

To design ultrareliable systems that can 
be validated, one must either demonstrate 
that these probabilities are very low (10 -5 
to 10“ 10 , depending on the application) or 
meet the aforementioned requirements of 
Byzantine tolerance. We believe that sys¬ 
tems that meet these very precise require¬ 
ments are considerably easier to validate 
analytically. Based on our own experience 
with digital systems, as well as that of 
others, 3 we also believe that such failures 

Even though four FCRs are required to 
tolerate one arbitrary fault, it is not neces¬ 
sary to use four processors in a system. We 
built triply redundant versions of the AIPS 
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Figure 1. Fault containment regions (FCRs) and interconnections in the AIPS quad-redundant fault-tolerant processor. 


Fault-Tolerant Processor (FTP) to comply 
with all requirements by providing extra 
FCRs. The FCRs took the form of indepen¬ 
dent data-replicating devices, also called 
interstages. We also built a quadruply re¬ 
dundant version with four interstages (for 
a total of eight FCRs) that can tolerate any 
two sequential arbitrary FCR failures. 9 
Because it performs only a two-round ex¬ 
change, this system can tolerate some (but 
not all) double simultaneous faults (see 
Figure 1). 

We also built a fault-tolerant parallel 
processor in which only three processors 
can mask an arbitrary failure. 7 We achieved 
this by placing the minimum four FCRs 
into the network elements that intercon¬ 
nect the processors and execute the source 
congruency algorithm. 

Input validity. A redundant input source 
satisfies the condition of validity for exter¬ 
nal inputs. Typically, critical sensors are 
replicated and interface with different 
channels of the redundant computer. Fig¬ 


ure 1 shows the quad-redundant FTP with 
a triplicated sensor. The three redundant 
sensors (SI, S2, and S3) physically inter¬ 
face with channels A, B, and C, respective¬ 
ly. The design provides a valid and congru¬ 
ent sensor value to all four channels. 

Channel A reads sensor S1, and all four 
channels execute the two-round exchange 
algorithm that culminates in their receiv¬ 
ing a congruent value of SI, say, VI. The 
process repeats for sensors S2 and S3. Now 
all four channels have the same three sen¬ 
sor values, say, VI, V2, and V3. 

To obtain a valid sensor value V, the 
system must compare and vote the three 
sensor values. However, a bit-for-bit vot¬ 
ing of redundant sensors is usually not 
possible since sensors measure such real- 
world parameters as pressure, tempera¬ 
ture, angle, and acceleration, which are all 
analog quantities. Even under no-fault 
conditions, digital representations of re¬ 
dundant sensor values differ. However, 
since the sensor values do represent real- 
world physical quantities, one can use a 


number of reasonableness checks (such as 
rate of change and minimum-maximum 
range of values) to filter out a grossly 
misbehaving sensor. Midvalue select, av¬ 
erage, or mean value of the remaining sen¬ 
sors can then be used to arrive at a valid 
sensor value in all channels. Note that the 
value will also be congruent since all chan¬ 
nels execute an identical sensor-redun¬ 
dancy management algorithm with con¬ 
gruent sensor inputs. 

We have designed two systems — AIPS, 
described in the next section, and the Fault 
Tolerant Parallel Processor 7 — to meet the 
requirements discussed above. 

AIPS 

Requirements. Digital computers with 
centralized architectures have significant¬ 
ly enhanced the performance of aerospace 
vehicles. Although these centralized sys¬ 
tems have served their applications well, 
many advanced aerospace vehicles could 
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Table 1. AIPS design requirements. 


Requirement 

Specification 

Short-term reliability 

10" 9 failure probability* at 10 hours with no 


repair 

Long-term reliability 

0.95 failure probability* at 5 years with no repair 

Fault tolerance 

Af-fail operation* (hardware only) 

Throughput 

100 MIPS*t (expandable) 

Memory 

500 Mbytes*f (expandable) 

I/O 

100 Mbits/sec.*t (expandable) 

Transport lag 

5 ms* 

Cycle rate 

100 Hz* 

System real-time clock 

Variable* 

accuracy/quantization 



‘Varies with technology, mission 


benefit significantly from distributed com¬ 
puter systems. These applications include 
the Space Station, the Aeroassisted Orbital 
Transfer Vehicle, the Advanced Launch 
System, the National Aerospace Plane, and 
advanced fighter aircraft for the US Air 
Force and Navy. 

Fault-tolerant distributed systems are 
superior in some ways to centralized sys¬ 
tems and are better suited to the highly 
integrated electronic information systems 
of future vehicles. These attributes include 

• function integration, 

• parallel computation, 

• graceful performance growth, 

• selective technology upgrade, 

• appropriate levels of function reliabil¬ 
ity, 

• graceful degradation of system capa¬ 
bilities in the presence of faults or 
damage, and 

• efficient use of hardware resources. 

Furthermore, the architectural concept 
should be validated so that the physical 
realization of these attributes in hardware 
and software meet stibh quantitative mis¬ 
sion requirements as throughput perfor¬ 
mance, transport lag, and mission success 
probability. The implementations must also 
be well within such mission constraints as 
cost, weight, volume, and power. 

The overall program objective of AIPS, 
developed under the sponsorship of NAS A, 
is to produce a knowledge base that allows 
designers to achieve validated fault-toler¬ 
ant, distributed, computer-system archi¬ 
tectures for a broad range of aerospace 
vehicles. Table 1 summarizes the overall 
AIPS design requirements for seven aero¬ 


space applications, obtained by an exten¬ 
sive survey of NASA centers and pub¬ 
lished as Draper Report AIPS-83-50. The 
architecture conceived to meet these re¬ 
quirements is based on the notion of pre¬ 
validated building blocks. 

The AIPS multicomputer architecture 
consists of hardware and software building 
blocks that can be configured according to 
certain design rules and guidelines to meet 
the specific requirements of a given appli¬ 
cation. 

Building blocks. The hardware build¬ 
ing blocks consist of FTPs, networks, and 
interfaces (see Figure 2). FTPs are general- 
purpose computers that can be built in 
redundancy levels that vary from simplex 
to quadraplex, using up to four identical 
channels to meet different levels of reli¬ 
ability requirements. The communication- 
media networks are circuit-switched nodes 
joined by full-duplex links. The networks 


can be configured in ring, braided mesh, 
and irregular mesh topologies. Networks 
can also be made redundant. They connect 
FTPs to I/O devices (called I/O networks) 
and to other FTPs (called intercomputer or 
IC networks). 

I/O and IC networks consist of identical 
nodes and links. The interface building 
blocks connect an FTP channel to an I/O 
network, which is then called the I/O se¬ 
quencer or IOS, and to the IC network, 
which is then called the IC interface se¬ 
quencer or ICIS. 

The software building blocks furnish 
local, I/O, and intercomputer system ser¬ 
vices, and the system manager. These 
building blocks provide the services nec¬ 
essary in a traditional real-time computer, 
such as task scheduling and dispatching, 
and communication with sensors and actu¬ 
ators. The software also supplies the re¬ 
dundancy-management services necessary 
in a redundant computer or a distributed 
system, such as interfunction communica¬ 
tion across processing sites, management 
of distributed redundancy, network man¬ 
agement, and function migration between 
processing sites. 

Virtual architecture. A unique attribute 
of AIPS (and other Draper-designed fault- 
tolerant computers) is that redundancy and 
its management are transparent to the ap¬ 
plication software. They are also transpar¬ 
ent to all system software except for those 
services that manage the redundancy. This 
attribute allows programmers to develop 
and validate most software on a simplex 
processor in a familiar development envi¬ 
ronment that uses mature tools. We call the 
architecture that appears to the program¬ 
mer the virtual architecture. 

The AIPS virtual architecture is a con¬ 
ventional multicomputer that consists of a 
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Figure 3. AIPS overall virtual architecture. 


number of FTP processing sites and exter¬ 
nal interfaces (see Figure 3). An IC bus 
links the processing sites. An FTP at any 
processing site can also access varying 
numbers and types of I/O buses, which are 
separate from the IC bus. Separate buses 
carry sensor and intercomputer data be¬ 
cause the bandwidth and reliability re¬ 
quirements for these two classes of data in 
most real-time systems vary widely. The 
I/O buses may be global, regional, or local 
in nature. I/O devices on the global I/O bus 
are available to all, or at least a majority of, 
the FTPs. Regional buses connect I/O de¬ 
vices in a given region to the processing 
sites located in their vicinity. Local buses 
connect an FTP to the I/O devices dedicat¬ 
ed to that computer. Additionally, I/O de¬ 
vices may connect directly to the internal 


bus of a processor and be accessed as 
though they reside in computer memory 
(like memory-mapped I/O). 

The regional and global buses allow 
sharing of raw sensor data among func¬ 
tions that reside on different processing 
sites, thus reducing the overall system cost. 
These buses also allow functions to mi¬ 
grate between FTPs in real time in the 
event of faults, damage, or change in mission 
phase and work load. The memory-mapped 
I/O accesses time-critical sensors to meet 
stringent transport lag requirements for 
real-time control applications. 

Figure 4 shows the virtual architecture 
of a processing site. It consists of three 
sections: computational, I/O, and the re¬ 
sources shared between them. The compu¬ 
tational and I/O sections are identical, con¬ 


ventional processor architectures. Each 
consists of a processor, memory, interval 
timers, and memory-mapped I/O unique to 
each processor. Although identical in 
hardware design, the computational pro¬ 
cessor, or CP, is typically devoted to appli¬ 
cation functions (such as executing a vehi¬ 
cle control law) while the I/O processor, or 
the IOP, is devoted to such I/O functions as 
reading and validating sensors and sending 
out actuator commands. The CP and IOP 
communicate with each other via shared 
memory. Other shared resources include a 
data-exchange mechanism that votes data 
with other redundant channels in this FTP, 
a real-time clock, and interfaces to several 
I/O buses and the IC bus. 

Physical architecture. The parameters 
that define the physical architecture in¬ 
clude 

• redundancy levels of FTPs; 

• interconnections of redundant chan¬ 
nels in an FTP; 

• redundancy levels of sensors, actua¬ 
tors, and other I/O devices; 

• cross-strapping of I/O devices to chan¬ 
nels of FTPs and the redundancy levels 
of their interfaces; and 

• redundancy levels of IC and I/O net¬ 
works and their physical topologies. 

Figure 1 showed the physical architec¬ 
ture of the quad-redundant AIPS FTP. It is 
designed strictly according to the theory 
we discussed and complies with all re¬ 
quirements for tolerating two sequential 
Byzantine failures of FCRs. In addition to 
redundancy, other features that provide 
fault tolerance include watchdog timers, 
processor interlocks, a privileged operat¬ 
ing mode, hardware and software excep- 



Figure 4. AIPS processing-site virtual architecture. 
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Figure 5. AIPS engineering model configuration. 


tion handlers, and self-testing. A majority 
of correctly operating channels can disable 
all outputs of a failed channel using the 
processor interlock mechanism. A channel 
that is “failed active” cannot transmit erro¬ 
neous data or commands on I/O and IC 
networks or to local I/O devices. 

The physical realizations of the virtual 
I/O and IC buses are the fault- and damage- 
tolerant circuit-switched networks. A net¬ 
work consists of a number of full-duplex 
links interconnected by circuit-switched 
nodes. In steady state, the circuit-switched 
nodes route information along a fixed 
communication path, or virtual bus, within 
the network, without the delays associated 
with packet-switched networks. Once the 
virtual bus is set up within the network, its 
protocols and operation are similar to those 
of typical multiplex buses. 

Although the network performs exactly 
as a bus does, it is far more reliable and 
damage tolerant than a linear bus. A single 
fault or limited damage can disable only a 
small fraction of the virtual bus, typically 
a node or a link connecting two nodes. 
Reconfiguring the network around the faulty 
element constructs a new virtual bus. The 
nodes are sufficiently intelligent to recog¬ 
nize reconfiguration commands from the 
network manager (explained in the system 
services section), which resides in one of 
the FTPs. Adding more nodes linked to 
spare ports in existing nodes easily ex¬ 
pands the network. 

To maintain fault-tolerance requirements, 
each FTP channel receives data from all 
three IC network layers but can physically 
transmit on only one layer (see Figure 5). 
For example, simplex 1 can only transmit 
on layer L, as shown by an outgoing arrow 
on the left, but receives on all three layers, 
as shown by three incoming arrows. Simi¬ 
larly, channels A, B, and C of FTP4 can 
transmit only on layers L, M, and N, re¬ 
spectively (again, as shown by a single 
outgoing arrow from each channel to one 
IC network layer). All three layers of the 
IC network operate together to transmit 
and receive data. Since all channels of a 
triplex site are executing the same code 
synchronously, the three channels (each 
channel transmitting on a different layer) 
transmit identical messages. Thus, within 
some skew, the redundant layers of the 
network contain the same message. This 
allows the receiving site to vote the three 
layers, masking any failure. Although they 
always receive on three layers, duplex sites 
can transmit on only two of the three layers 
of the network, and simplex sites can trans¬ 
mit on only one of the them. Thus, mali¬ 


cious failure of a channel can disrupt only 
one layer. 

For access arbitration purposes, the tri¬ 
plex network is treated as a single entity. 
FTPs, regardless of their redundancy level, 
contend for all three layers of the network. 
At the end of the contention sequence one 
— and only one — FTP can access three 
layers of the network. 

The IC networks, the FTP interfaces to 
the networks (ICISs), and the arbitration 
logic are designed in strict accordance with 
the theory we advanced in the Require¬ 
ments and design approach section. 10 The 


system provides error-masking capability 
for intercomputer communication between 
triplex (or higher redundancy level) FTPs. 
An arbitrary hardware fault (including 
Byzantine faults) within the system cannot 
disrupt communication between FTPs of 
triplex or higher redundancy level. 

System services. Each processing site 
can operate autonomously, particularly to 
perform critical functions. However, the 
system services software allows a coordi¬ 
nated information processing system to 
provide attributes superior to the more fed- 


May 1991 
















































Table 2. Relationships between requirements and attributes. 


Requirement 

Attributes 

100-Hz cycle rate 

Concurrent I/O, computation, implementation 
technology, low fault-tolerance overhead, low 
system services overhead, transient fault tolerance 

Adaptability 

Layered system services, prevalidated building blocks, 
reconfigurability, simplex programming model 

Availability 

Diagnosability, function migration, low component 
failure rate, non-Byzantine-resilient fault tolerance, 
real-time operation, reconfigurability, repairability, 
software fault avoidance 

Cost-effectiveness 

Copies in only 2/+ 1 fault containment regions, 
flexible function allocation, graded redundancy, 
low fault-tolerance overhead, software development 
environment 

Environment 

Implementation technology 

Expandable I/O 

Implementation technology, variable local I/O 

Expandable memory 

On-line memory, shared mass memory 

Expandable throughput 

Low fault-tolerance overhead, low I/O network 
transport delay, low intercomputer network delay, 
low system services overhead, variable number of 
processing sites 

Function distribution 

Function migration, variable number of processing 

Graceful degradation 

Byzantine resilience, function prioritization, variable 
number of processing sites, variable number of 
processors per channel 

Hardware /V-fail 
operation 

Ada programming language, diagnosability, 
reconfigurability 

Low life-cycle cost 

Diagnosability, low component failure rate, portability 
of software tools, prevalidated building blocks, 
reconfigurability, simplex programming model 

Low transport lag 

Implementation technology, low component failure 
rate, low I/O network transport delay, low system 
services overhead, memory-mapped I/O 

Maintainability 

Diagnosability, low fault-tolerance overhead, 
reconfigurability, repairability, testability 

Mission reliability 

Byzantine resilience, damage tolerance, function 
migration, graded redundancy, intercomputer 
network, latent fault detection, low competence 
failure rate, real-time operation, reconfigurability, 
software fault tolerance, transient fault tolerance 

Modularity 

Common-mode fault tolerance, graded redundancy, 
heterogeneous load modules, identical fault tolerant 
processor design, intercomputer network, layered 
system services, prevalidated building blocks, 
symmetric computational processor or I/O processor 

System real-time clock 

Timer-based interrupt 


erated systems typical for current aero¬ 
space vehicles. 

The local system services in each FTP 
include initialization; a real-time operat¬ 
ing system; local resource allocation; fault 
detection, isolation, and reconfiguration 
(FDIR); and local time management. The 
real-time operating system supports task 
execution management, including priority 
scheduling, and time and event occurrence. 
It is also responsible for task dispatching, 
suspension, and termination. It uses the 
vendor-supplied Ada Run Time System 
(RTS) and includes additional features for 
the AIPS real-time distributed operating 
system. 

FDIR detects and isolates hardware faults 
in the CPs, IOPs, and shared hardware. It 
synchronizes both groups of processors in 
the redundant channels of the FTP and 
disables outputs of failed channel(s) through 
interlock hardware. FDIR also performs 
CPU hardware exception handling and 
down-modes and up-modes hardware in 
response to configuration commands from 
the system manager. It also detects tran¬ 
sient hardware faults and runs low-priority 
self-tests to detect latent faults. The local 
time manager works in cooperation with 
the system time manager to keep the local 
real time initialized and consistent with the 
universal time. 

I/O system services provide communi¬ 
cation between the user and external devic¬ 
es (sensors and actuators). They also detect 
faults, and isolate and reconfigure the I/O 
network hardware and the IOS. 

The IC user communication service is 
designed along the seven-layer Open Sys¬ 
tems Interconnect model. It provides local 
and distributed interfunction communica¬ 
tion (point-to-point or broadcast mode) 
transparent to the user. It also provides 
synchronous and asynchronous communi¬ 
cation, performs error detection and source 
congruency on inputs, and records and re¬ 
ports IC network errors to the network 
layer managers. The IC network manager 
is responsible for the fault detection, isola¬ 
tion, and reconfiguration of that network. 

The system manager is a collection of 
system-level services. The system resource 
manager allocates migratable functions to 
FTPs. This involves monitoring various 
triggers for function migration such as fail¬ 
ure or repair of hardware components, mis¬ 
sion phase or work-load change, operator 
or crew requests, and timed events. The 
system FDIR collects status from the IC 
network managers, the I/O network man¬ 
agers, and the local FTP redundancy 
managers. It resolves conflicting local 
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Table 3. AIPS/ALS performance projections. 


Attribute 

Specification 

Raw CPU throughput 

15 MIPS (Digital Avionics Instruction Set 
mix) per processor 

Total overhead 

Computational processor: 11% of throughput 
I/O processor: 16% of throughput 

Useful throughput 

Computational processor: 13.35 MIPS 

I/O processor: 11.85 MIPS 

Fault-tolerant processor: 25.2 MIPS 

Fault-tolerant clock 

2 MHz 

Data-exchange bandwidth 

64 Mbits/sec. 

I/O and intercomputer 
network bandwidth 

100 Mbits/sec. 

Interfunction communication 
(fault-tolerant processor 
to fault-tolerant processor) 

1.28 ms 


fault-isolation decisions, isolates unre¬ 
solved faults, correlates transient faults, 
and handles processing site failures. The 
system time manager, in conjunction with 
the local time manager on each FTP, main¬ 
tains a consistent time across all FTPs. 

Engineering model. We developed an 
AIPS engineering model to demonstrate 
and validate the major architectural con¬ 
cepts and attributes. The model includes 
all hardware and software building blocks 
described earlier and consists of four pro¬ 
cessing sites connected by a three-layer IC 
network. Three processing sites are triply 
redundant FTPs, and the fourth is a sim¬ 
plex processor. One processing site also 
accesses a 15-node I/O network. Each 
channel of each FTP contains two Motoro¬ 
la 68010 microprocessors with 4 Mbytes of 
memory each, data exchange and voting 
hardware, monitor-interlock, an IOS, and 
an ICIS. FTPs using Motorola 68020 mi¬ 
croprocessors in quadruply redundant ver¬ 
sions have-also been fabricated. The I/O 
and IC networks use 2-MHz HDLC proto¬ 
col. The laboratory model does not contain 
a mass memory. 

We wrote the system software in Ada. 
The basic operating system incorporates 
vendor-supplied Ada RTS, which we en¬ 
hanced with certain real-time capabilities. 
Over 100,000 lines of Ada source code 
comprise system services. All AIPS hard¬ 
ware and software has been integrated and 
operated under fault-free conditions as well 
as in the presence of various faults. How¬ 
ever, we have not yet implemented the 
function migration concept. Extensive 
measurements of performance- and reli¬ 
ability-related parameters have been ob¬ 
tained on the engineering model." 

Architecture and performability 
knowledge base. The AIPS program goal 
is to produce a knowledge base that allows 
achievement of validated fault-tolerant 
distributed computer architectures at re¬ 
duced cost. We have compiled a very ex¬ 
tensive knowledge base to this end. 

The knowledge base involves many re¬ 
lationships among entities called require¬ 
ments, attributes, rules, specifications, and 
guidelines. A requirement is a quantitative 
or qualitative statement of an AIPS mis¬ 
sion objective, such as availability. An 
attribute is an unambiguous statement of 
an AIPS characteristic, such as Byzantine 
resilience. A rule is a principle that must be 
followed to assure that a higher-level AIPS 
attribute holds, and a specification is an 
aggregate of rules that describe the rele¬ 


vant characteristics of an AIPS building 
block. The specification should be suffi¬ 
ciently detailed to allow one “unskilled in 
the art” to construct the component. Final¬ 
ly, a guideline is a statement of policy or 
philosophy based on our laboratory’s ex¬ 
perience, along with a statement of the 
effects of deviating from the guideline. 

The interentity relationships may be in¬ 
tuitive, quantitative, or formally defined. 
Our methodology depicts the entities and 
relationships in a directed graph format. 
The set of requirements, attributes, rules, 
specifications, guidelines, and their rela¬ 
tionships provides a framework for struc¬ 
turing and interconnecting AIPS building 
blocks into a computational system that 
satisfies the mission requirements. 

Table 2 depicts the top two tiers of the 
directed graph. The mission requirements 
appear in the left column. One or more 
directed arcs (not shown) emanate from 
each requirement to one or more AIPS 
attributes, shown in the right column. We 
assert that a system that possesses the set of 
attributes corresponding to a requirement 
meets that requirement. At successive lay¬ 
ers of the graphical structure, each attribute 
implies, in turn, an additional set of at¬ 
tributes, architectural rules, or architectur¬ 
al guidelines. At the lowest level of the 
graph reside the AIPS architectural rules 
and guidelines, which provide sufficiently 
detailed design guidance to ensure that the 
mission requirements are achieved by the 
implementation. 

Under a recent contract with the NASA 
Langley Research Center, we synthesized 


an AlPS-based fault-tolerant avionics ar¬ 
chitecture for the Advanced Launch Sys¬ 
tem (ALS). 12 NASA and the US Depart¬ 
ment of Defense are jointly developing the 
ALS vehicle to launch heavy payloads into 
low earth orbit at one tenth the cost (per 
pound of payload) of the current genera¬ 
tion of launch vehicles. 

To illustrate the AIPS performability 
knowledge base, we summarize some AIPS 
characteristics for the ALS avionics archi¬ 
tecture. 

The ALS processor will be a 40-MHz, 
R3000 from MIPS Inc. (or a similar 32-bit 
reduced instruction-set computing archi¬ 
tecture). The CPU module will have both 
RAM and ROM for a total of 1 to 4 Mbytes 
with a local bus interface for memory ex¬ 
pansion. A 2-MHz fault-tolerant clock will 
synchronize interchannel operations and 
provide a data-exchange bandwidth of 64 
Mbits/sec. The I/O and IC network proto¬ 
col will be based on the Fiber Distributed 
Data Interface (FDDI) standard with a bit 
rate of 100 Mbits/sec. A modified Laning 
Poll will be used to access the network of 
virtual buses rather than the FDDI token. 
Table 3 summarizes the AIPS/ALS perfor¬ 
mance projections. 

All nonpropulsion ALS functions such 
as guidance, navigation, and control re¬ 
quire a total of 8.8 million instructions per 
second, executable by one FTP. Because 
the ALS design guidelines require that the 
engine controller be colocated with the 
engine, each ALS engine has a dedicated 
FTP to perform propulsion control func¬ 
tions. Using the projected hardware-fail- 
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ure and recovery rates, we solved the ana¬ 
lytical models to predict the ALS avionics 
reliability. The probability of failure of a 
quadruply redundant FTP was projected to 
be8.9x 10‘ 9 forthe 10-minute boost phase, 
and 5.3 x 1CL 7 for the 48-hour on-orbit phase, 
assuming class B components. The launch 
availability — that is, the probability that 
the FTP will be in a fault-masking config¬ 
uration — was estimated to be 0.9988 after 
a week on the launch pad. 

The applications of the fault-tolerant 
computers described here have included a 
jet engine controller, a nuclear power plant 
trip monitor, research test beds, and under¬ 
sea vehicle controls. A US Department of 
Defense Advanced Research Projects 
Agency-sponsored Unmanned Underwa¬ 
ter Vehicle, about 36 feet long and 44 
inches in diameter, is controlled by a tri¬ 
plex FTP and has successfully undergone 
sea trials. A quadruply redundant version 
of the FTP, programmed in Ada, was deliv¬ 
ered in July 1990 to the US Army Strategic 
Defense Command in Huntsville, Alabama, 
for use in Strategic Defense Initiative Or¬ 
ganization Battle Management/Command 
Control and Communications functions. 
Another quad FTP under fabrication will 
be used to control the Navy’s latest nuclear 
attack submarine, the SSN-21 Seawolf. 


S ignificant research at Draper has 
laid a firm theoretical foundation 
for the design of virtually perfect 
mechanisms for tolerating random hard¬ 
ware faults. We are extending it to common¬ 
mode faults, which affect more than one 
FCR simultaneously. We are investigating 
a number of approaches in this regard, 
including formal methods and design di¬ 
versity. We are also researching use of 
authenticated protocols to provide Byzan¬ 
tine resilience at a lower hardware cost. 
Redundant architectures that use encoded 
rather than triplicated memory, yet can still 
provide 100 percent fault coverage, are 
also under design. Reduced instruction-set 
microprocessors, fiber optic buses, and 
multichip modules are some of the tech¬ 
nologies being investigated to reduce the 
overall hardware failure rates and simplify 
designs for validation. ■ 
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HARTS: 

A Distributed 
Real-Time Architecture 


Kang G. Shin, University of Michigan 


T he growing importance of real¬ 
time computing in numerous ap¬ 
plications, such as aerospace and 
defense systems and industrial automation 
and control, poses problems for computer 
architectures, operating systems, fault tol¬ 
erance, and evaluation tools. The interplay 
of three major components characterizes 
real-time systems. First, time is the most 
precious resource to manage. Tasks must 
be assigned and scheduled to be completed 
before their deadlines. Messages must be 
sent and received in a timely manner be¬ 
tween the interacting real-time tasks. Sec¬ 
ond, reliability is crucial, since failure of a 
real-time system could cause an economic 
disaster or the loss of human lives. Third, 
the environment in which a computer oper¬ 
ates is an active component of any real¬ 
time system. For example, in a “drive by 
wire” transportation system, in which im¬ 
portant functions such as emission control 
and braking are automated with comput¬ 
ers, it would be meaningless to consider 
the on-board computers without consider¬ 
ing the automobile itself. 

Because their multiplicity of processors 
and internode routes gives them the poten¬ 
tial for high performance and high reli¬ 
ability, distributed systems with point-to- 
point interconnection networks are natural 
candidate architectures for time-critical 
applications. This article focuses on the 
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Consisting of shared- 
memory multiprocessor 
nodes interconnected 
by a wrapped 
hexagonal mesh, 
HARTS is designed to 
meet the special 
communications and 
I/O needs of time- 
critical applications. 


design, implementation, and evaluation of 
a distributed real-time architecture called 
HARTS (hexagonal architecture for real¬ 
time systems), with emphasis on its sup¬ 
port of time-constrained, fault-tolerant 
communications and I/O requirements. 
Currently under development at the Uni¬ 
versity of Michigan’s Real-Time Com¬ 
puting Laboratory (RTCL), HARTS con¬ 
sists of shared-memory multiprocessor 
nodes, interconnected via a wrapped hex¬ 
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agonal mesh. This architecture is intended 
to meet three main requirements of real¬ 
time computing: high performance, high 
reliability, and extensive I/O.* 

High-level architecture 

The primary goal of HARTS is the study 
of low-level architectural issues, such as 
message buffering, instruction set design, 
scheduling, and routing, in a setting that 
gives designers internal access to many 
system parameters. To meet this goal, my 
colleagues at RTCL and I used a hybrid 
system of commercially available proces¬ 
sors and custom-designed interfaces. Sev¬ 
eral processor cards are grouped to form a 
cluster of application processors (APs). 
Each cluster serves as a multiprocessor 
node and is interconnected by custom in¬ 
terfaces to form a distributed system. The 
presence of both multiprocessor and dis¬ 
tributed aspects permits investigating the 
behavior of real-time tasks under either 
architectures. In parallel with the hardware 


♦Although predictability of task execution behavior is 
essential for any real-time system design to guarantee 
on-time completion of tasks, it is not an architectural 
issue but an operating system issue. Real-time systems 
architects must provide hardware facilities on which 
one can readily build an operating system that guarantees 
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development, our work on a real-time op¬ 
erating system called HARTOS 1 influences 
the specification, architecture, and imple¬ 
mentation of the custom-designed HARTS 
components. 

Node architecture. Each node in the 
testbed consists of up to three APs, a sys¬ 
tem controller, a shared memory segment, 
an Ethernet processor, and the network 
processor (NP), a custom-designed inter¬ 
face to the interconnection network. 

The APs are commercially available 
VME bus multiprocessing engines based 
on Motorola’s MC68020. Each processor 
card has four major sections: a CPU core, 
a VME bus interface, a memory system, 
and a VMX bus interface. The CPU core 
consists of a 32-bit 16-MHz MC68020 
CPU, an MC68881 floating-point proces¬ 
sor, and an MC68851 paged memory 
management unit. The memory subsystem 
provides four megabytes of high-perfor¬ 
mance dual-ported dynamic RAM, with an 
additional 256 bytes of special mailbox 
hardware. This mailbox feature facilitates 
efficient interprocessor communication by 
allowing a remote processor to write a 
semaphore that automatically interrupts the 
local processor. 


The Ethernet processor card supports 
several functions for the nodes, although it 
is not a permanent HARTS component. 
First, it provides a secondary means of 
distributing code and data. This is espe¬ 
cially important during the early stages of 
development of the network interfaces. 
Second, the high-level protocols that man¬ 
age reliable packet handling and provide 
internode communication can be experi¬ 
mentally tested on the Ethernet processor. 
Third, the Ethernet processor is used to 
collect experimental data by monitoring 
the APs and network interfaces with min¬ 
imal interference. 

Interconnection network. A distribut¬ 
ed system’s interconnection network often 
connects thousands of homogeneously 
replicated processor-memory pairs, which 
are called processing nodes (PNs). All 
synchronization and communication be¬ 
tween PNs for program execution are via 
message passing. The homogeneity of PNs 
and the interconnection network is very 
important because it allows cost and per¬ 
formance benefits from the inexpensive 
replication of multiprocessor components. 2 
It is preferable that each PN in the multi¬ 
processor have fixed connectivity so that 


standard VLSI chips and communication 
software can be used. Also, the intercon¬ 
nection network should contain a reason¬ 
ably high degree of connectivity so that 
alternative routes can be made available to 
detour faulty nodes and links. More im¬ 
portant, the interconnection network must 
facilitate efficient routing and broadcast¬ 
ing to achieve high performance in task 
execution. For structural flexibility, a sys¬ 
tem must also possess fine scalability, 
measured in terms of the number of PNs 
necessary to increase the network’s di¬ 
mension by one. 

To meet these requirements, we consid¬ 
ered several topologies, including hyper¬ 
cubes, square meshes, 3D tori, hexagonal 
meshes, and octal meshes. Of these, the 
hexagonal (H) mesh best meets the re¬ 
quirements of fixed connectivity and pla¬ 
nar architecture for easy VLSI and com¬ 
munications implementation, fine 
scalability, reasonably high fault toler¬ 
ance, and ease of construction. (Detailed 
comparisons of the H-mesh to other to¬ 
pologies are given by Stevens 2 and by Chen, 
Shin, and Kandlur. 3 The robustness of an 
H-mesh to link and node failures is shown 
by Olson and Shin. 4 ) Hence, we chose a C- 
wrapped (“C” stands for continuous) H- 
mesh topology to interconnect HARTS 
nodes. 

H-mesh size (the term “dimension” was 
used in an earlier article 3 ) is defined as the 
number of nodes on its peripheral edge. 
One can visualize what is happening in the 
C-wrapping by first partitioning the nodes 
of a nonwrapped H-mesh of size e, denoted 
by H e , into rows in three different directions. 
The mesh can be viewed as composed of 
2e-l horizontal rows (called the d 0 direc¬ 
tion), 2e -1 rows in the 60-degree clockwise 
direction (called the d, direction), or 2e-l 
rows in the 120-degree clockwise direction 
(called the d 2 direction). In each of these 
partitions we label from the top the rows R 0 
through /?2 c- 2- The C-wrapping is then 
performed by connecting the last node in R , 
to the first node in Rp+e+i^e-i for each i in 
each of the three partitions, where [a] b 
denotes a mod b. Figure 1 illustrates an 
example of a C-wrapped // 3 in which the 
links on the periphery (represented by 
dashed-line arrows) are connected to the 
nodes as indicated by their labels. 

The C-wrapped H-mesh is isomorphic 
to the interconnection topology presented 
by Stevens. 2 However, the formalism just 
described allows uniform treatment of 
message routing between all pairs of nodes 
and does not require any special treatment 
of the wrap lines, as was necessary in 
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Stevens’ topology when the axial offset 
was between e and 2(e-l). 

A C-type wrapping has several salient 
properties, as shown by Chen, Shin, and 
Kandlur. 3 First, this wrapping results in a 
homogeneous network. Consequently, any 
node can view itself as the center of the 
mesh (labeled as node 0 in Figure 1). Second, 
the diameter of an H e is e-1. Third, there is 
a simple, transparent addressing scheme 
that uses only one coordinate — instead of 
three as in Stevens’ topology — to unique¬ 
ly identify any node in an H-mesh. An 
example of this addressing for an H 4 is 
shown in Figure 2a, where all edges are 
omitted for clarity. On the basis of this 
addressing scheme, one can determine the 
shortest paths between any two nodes with 
a 0( 1) algorithm; that is, the complexity is 
constant and independent of system size. 
Note that at each node on a shortest path 
there are at most two different neighbors of 
the node to which the shortest path runs. 
Fourth, with this addressing scheme one 
can devise a simple routing algorithm that 
can be efficiently implemented in hardware, 
as shown by Dolter, Ramanathan, and Shin. 5 

To send a message, the source calculates 
the shortest paths to the destination and 
encodes this routing information into three 
integers denoted by m 0 , m \, and m 2 , which 
represent the number of hops from the 
source to the destination along the d 0 , d\ , and 
d 2 directions, respectively. Before sending 
the packet to an appropriate neighbor, in¬ 
termediate nodes update these values to 
indicate the remaining hops in each direction 
to the destination. Hence, m 0 = m\=m 2 = 0 
indicates that the packet has reached its 
destination. 

Suppose node 11 sends a message to 
node 5 in the H 4 of Figure 2. The original 
H 4 is given in Figure 2a and H 4 ( 11) — node 
11 is placed at the center of the H 4 — is in 
Figure 2b. From the Chen-Shin-Kandlur 
routing algorithm, we get m 0 = 0, m t = -2, 
and m 2 = -1. Note that the route from node 
11 to node 5 in Figure 2b is isomorphic to 
that from node 0 to node 31 in Figure 2a. 
This is not a coincidence but rather a con¬ 
sequence of the homogeneity of H 4 . 

Applications in various domains require 
an efficient method for a node to broadcast 
a message to all the other nodes in an H- 
mesh. Due to interconnection costs, it is 
very common to use point-to-point commu¬ 
nications for broadcasting. Without loss of 
generality, one can assume the center node 
is the broadcast source. The set of nodes that 
has the same distance from the source node 
is called a ring. The main idea of this algo¬ 
rithm is to broadcast a message, ring by 


ring, toward the periphery of an H-mesh. 
The algorithm consists of two phases. In the 
first phase, which takes three steps, the 
message is transmitted to the origin’s six 
nearest neighbors. Note that there are six 
corner nodes in each ring. In the second 
phase, which takes e-1 steps, the six corner 


nodes of each ring send the message to two 
neighboring nodes, while all other nodes 
propagate the message to the next node in 
the same direction as the previous trans¬ 
mission. Figure 3 is an example of H 4 
broadcasting. The numeric labels denote 
the communication step numbers. 
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Figure 2. Example of routing in an H 4 : (a) original H 4 ; (b) H 4 with node 11 
placed at the center, H 4 (11). 
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Figure 3. Broadcasting in an H 4 . 
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Low-level architecture 

We have developed special hardware 
support for time-constrained, fault-toler¬ 
ant communications in HARTS, based on 
the addressing, routing, and broadcasting 
methods just described. Below, we dis¬ 
cuss the need for extra hardware for com¬ 
munication processing, the main functional 
requirements of the NP, and a system- 
level architecture that realizes these 
functions. 

Why communication hardware? Each 
node in a distributed system must be re¬ 
sponsible for packet processing, routing, 
and error and flow control. Real-time ap¬ 
plications impose additional functions re¬ 
lated to meeting deadlines, time manage¬ 
ment, and housekeeping. 

Packet processing can consume a sub¬ 
stantial number of processor cycles and, in 
the absence of communication hardware, 
can deprive the host (node) of much need¬ 
ed computation power. In particular, the 
host is saddled with breaking a message 
into packets for transmission, constructing 
packet headers and trailers, framing pack¬ 
ets, and calculating checksums. On recep¬ 
tion of packets, the receiving host has to 
depacketize the message, strip headers and 
trailers, and compute the checksum for 
error checking. Each time a packet is trans¬ 
mitted or received, the host must be inter¬ 
rupted and context-switched to routines 
that perform these chores. This introduces 
substantial overhead because contempo¬ 
rary off-the-shelf processors are optimized 
to compute with register and cache data, 
which are lost in a context switch. For 
time-constrained, fault-tolerant communi¬ 
cations, the host AP also has to handle 
several other functions that introduce sig¬ 
nificant computational overhead. These 
include message scheduling, route selec¬ 
tion for reliable and timely delivery of 
messages, and clock synchronization. 

All these functions divert significant 
computing power from time-critical appli¬ 
cations. It is therefore necessary to offload 
such processing from the AP to special 
communication-processing hardware — 
that is, the NP. 

Requirements of the network proces¬ 
sor. Before designing and building the NP, 
we identified required functions, which 
must include efficient support for message 
processing, low-latency message trans¬ 
mission, and support for time-constrained, 
fault-tolerant communications. The oper¬ 


ating system must establish deadline guar¬ 
antees based on these functions. 

Communication protocol processing. The 
NP’s main function is to offload communi¬ 
cation processing from the APs. When an 
AP needs to transmit a message, it provides 
the NP with information about the intended 
message recipient and the location of the 
message data. The NP’s function is then to 
execute the operations necessary to pass 
the message data through the various lay¬ 
ers of protocol down to the physical layer 
where it can be transmitted. In terms of the 
OSI (Open Systems Interconnection) ref¬ 
erence model, the NP is responsible for 
functions from the transport layer down to 
the physical layer. 

At the transport level, the NP establishes 
connections dependent only on the source 
and destination nodes, without concern for 
the route to be used. It also handles end-to- 
end error detection and message retrans¬ 
mission. 

At the network level, the NP selects 
primary and alternate routes for establishing 
virtual circuits, forms data blocks and 
segments, and reassembles packets at the 
destination node. There are various 
switching methods, such as virtual cut- 
through switching, wormhole routing, store- 
and-forward packet switching, and circuit 
switching. Depending on traffic conditions 
in the network and the message type, the 
NP chooses an appropriate switching 
method for the message. The NP also de¬ 
tects and corrects errors at this level. 

At the data link level, the NP provides 
access to the network for the messages. It 
performs framing and synchronization and 
packet sequencing. In addition to error 
checking at the network level, the NP 
performs checksum error detection and 
correction at this level. 

Low-latency message transmission. Low 
communication latency is a key goal for 
NP design, and it influences task migration, 
task distribution, and load sharing. Laten¬ 
cy impacts the system from application 
tasks down to hardware components. Be¬ 
cause a significant portion of latency occurs 
in communication processing, achieving 
low-latency communications is intimately 
related to the implementation of commu¬ 
nication protocols. 

Support for time-constrained communi¬ 
cations. The timely delivery of messages 
requires a global time base across the differ¬ 
ent nodes in HARTS. The NP is equipped 
with special hardware for clock synchroni¬ 


zation and message time-stamping, provid¬ 
ing the basis for the implementation of 
various real-time communication algorithms. 

The NP also must support multiple inter¬ 
rupt levels to manage messages with dif¬ 
ferent priority levels. The hardware must 
provide sufficient interrupt levels to give 
urgent messages priority over less urgent 
ones. Urgent messages must also have 
priority in the use of scarce resources such 
as message buffers and bandwidths. The 
NP must implement buffer management 
policies that maximize buffer space utili¬ 
zation while guaranteeing buffer availability 
to the highest priority messages. Similarly, 
if noncritical messages hold other resources 
needed by more critical messages, the NP 
must provide for resource preemption by 
the critical messages. 

Another important NP function is mon¬ 
itoring the network’s state in terms of traffic 
load and link failures. The traffic load 
affects the NP’s ability to send real-time 
messages to other processors, while link 
failures affect system reliability. It is also 
possible for the NP to track its host’s (or 
hosts’) processing load and use the infor¬ 
mation for load balancing, load sharing, 
and task migration. 

NP architecture. The NP architecture 
must support the functions just discussed. 
Although the HARTS NP architecture is 
similar to other communication architec¬ 
tures, 6 it has new features to facilitate real¬ 
time fault-tolerant communication. At the 
same time, it attempts to cost-effectively 
minimize message latency by intelligent 
management of messages and buffer mem¬ 
ory. 

The NP has five major components: the 
interface manager unit (IMU), the packet 
controller (PC), the routing controller (RC), 
the buffer memory, and the application 
processor interface (API), interconnected 
as shown in Figure 4. (The bus management 
unit and page management unit are auxil¬ 
iary components.) 

The API moves data between the NP and 
the host-node APs, while the RC moves 
data between the NP and the network. Within 
the NP, the IMU is the main processor that 
controls the movement and processing of 
message data. The buffer memory acts as a 
staging area for data to be transmitted to, or 
received from, the network, and for mes¬ 
sage data that must be temporarily stored at 
the node due to unavailability of outgoing 
links to the next node on the route to its 
destination. The RC implements the physi¬ 
cal layer protocols for accessing the net¬ 
work and routing data to the node’s neigh- 
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Figure 4. Block diagram of the network processor. 


bors. It also supports virtual cut-through 
and wormhole routing by moving a mes¬ 
sage from an incoming to an outgoing link 
without buffering the message at the NP. 
Finally, the PC performs such functions as 
checksumming, packet framing, and de¬ 
framing. 

Interface manager unit. The IMU 
packetizes and depacketizes messages, 
schedules messages with different levels 
of priority, decides on switching methods 
based on message priority levels and net¬ 
work state, monitors the network state, 
performs error correction and message 
acknowledgment, and implements various 
real-time communication algorithms. Ease 
of software and hardware development and 
support, and availability, make a general- 
purpose RISC processor a reasonable choice 
for the IMU. 

The IMU must provide multiple levels 
of interrupts and a short context switching 
time. To minimize message latency, the 
IMU must respond quickly to host requests 
for message transmission or reception 
services. The register window schemes in 
a typical RISC processor allow fast context 
switches, thus meeting this requirement. 

The IMU has memory that can be used to 
store code and data. It also has access to the 
buffer memory, the staging area for mes¬ 
sages being moved between the host and 
the network. To avoid excessive copying, 
the buffer memory usually serves as the 


IMU’s data memory. Hence, the buffer 
memory is part of the IMU’s address space. 

Buffer memory. The buffer memory 
consists of RAM for the buffers and a 
buffer management unit. It stores messag¬ 
es waiting to be transmitted to or from the 
current node, and it acts as a temporary 
storage area for messages being routed 
through the current node. The amount of 
memory needed, usually only a few 
megabytes, is determined by the usage 
patterns of the application tasks. 

The word size is 32 bits. With current 
DRAM access speeds of 70 nanoseconds, 
this gives a memory bandwidth as high as 
457 megabits per second. This bandwidth 
is sufficient for access by the RC, the API, 
and the IMU, and for refresh cycles. 
Therefore, expensive static RAM or mul¬ 
tiport memories are unnecessary. 

The buffer manager arbitrates between 
the IMU, the API, and the PC for access to 
the buffer. It also handles buffer memory 
refresh by periodically accessing rows in 
the DRAM. The access priorities given to 
these different sources can be static, dy¬ 
namic, or random, depending on the buffer 
management policy adopted. 

Another function of the buffer manager 
is to provide addresses of free buffers for 
storing incoming packet data and to de¬ 
termine the location of packets ready for 
forwarding to an outgoing link. In other 
words, the buffer manager keeps the list of 


free buffer pages and tracks the location of 
various messages stored in the buffer. In 
instances where a message or packet spans 
more than a single page, the buffer manager 
keeps track of linked pages. The buffer 
management policy for the free list and the 
buffer allocation policy can be implement¬ 
ed with a separate microcontroller or the 
IMU. 

Packet controller. The PC functions as a 
DMA (direct memory access) interface 
between the RC and the buffer memory, 
providing the IMU with inbound and out¬ 
bound channels on which to transmit 
messages from or receive messages into 
the buffer. It accesses the buffer memory 
through the arbitration block of the buffer 
manager and transmits and receives mes¬ 
sages without the IMU’s intervention. 

In transmitting and receiving packets, 
the PC performs the function of transpar¬ 
ently framing and deframing packets. It 
does this by adding start-of-packet and 
end-of-packet bytes to the data bytes and 
computing the checksum as a packet is 
being sent. On reception of packets at the 
destination NP, the PC removes the packet 
header and trailer and computes the 
checksum to detect transmission errors. 
The detection of errors is signaled to the 
IMU via an interrupt, to trigger an appro¬ 
priate recovery procedure. 

Another function of the PC is to time- 
stamp messages as they are received and 
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transmitted. As will be discussed later, 
hardware time-stamping support is crucial 
to clock synchronization. The time stamp 
is appended to the message before the 
checksum bytes. 

Routing controller. The RC is the inter¬ 
face between the NP and the network. It 
implements the physical layer and part of 
the data link layer. As Figure 5 shows, the 
RC consists of six receiver-transmitter pairs 
connected to the buffer manager and IMU 
through a time-sliced bus. The transmitters 
convert outgoing data into serial form for 
transmission on the outgoing serial line. 
Correspondingly, the receivers convert in¬ 
coming serial data into parallel form and 
forward the data to a transmitter for onward 
transmission, in the case of virtual cut- 
through or wormhole routing, or to the 
buffer manager, if the data is to be stored in 
the current node. A single half-duplex se¬ 
rial line connects each receiver to a trans¬ 
mitter in a neighboring node. 

A distinct feature of the RC is that the 
receivers can be microprogrammed to im¬ 
plement various routing algorithms used in 
HARTS. Various switching methods can 
also be programmed simultaneously into 
the RC and used selectively, on the basis of 


the type of messages being sent through the 
node and the network traffic at any particular 
time. This allows giving the highest 
switching and routing priority to critical 
messages, while optimizing the overall la¬ 
tency of other types of messages. 

AP interface. The interface between the 
NP and the host APs is a VME bus. Data 
copying between a host AP and the NP is 
done by the API, which is a DMA interface 
to the VME bus. There are two ways of 
designing this interface for data transfer: 
mapping the NP’s data memory into the 
host address space or copying data from 
the host’s data memory to the NP’s data 
memory. Mapping the NP into the address 
space of the host is may appear efficient, 
since it avoids the overhead of a system 
call. However, this mapping requires ded¬ 
icated memory management hardware and 
kernel support for mapped address spaces, 
and it also incurs the overhead of data 
access over the VME bus. Depending on 
the typical size of the messages, burst¬ 
mode DMA transfer from the host memory 
to the NP memory may be more efficient. 

In the burst-mode DMA transfer, the 
host initiates data transfer to the NP by 
writing to an API control register a pointer 


to the data in the host, as in a typical DMA 
sequence. The API then contends for the 
host VME bus and the NP buffer memory. 
When both resources are acquired, it cop¬ 
ies the message data in burst mode directly 
from the host to the NP buffers. Upon 
completion of the transfer, the IMU is 
notified, and communication processing 
can begin. A similar sequence of operations 
is performed in reverse order for message 
receipt. 

System evaluation 

We have evaluated HARTS, using 
modeling and simulation with actual pa¬ 
rameters derived from our implementation. 
Specifically, we examined how different 
switching methods can be combined to 
yield low latency. First, we evaluated the 
performance of virtual cut-through 
switching by developing analytic models 
and a low-level, event-driven simulator. 
Then, we compared virtual cut-through 
switching and wormhole routing. 

Modeling and simulation of virtual 
cut-through. Since real-time applications 
normally require short response times, 
simple store-and-forward switching 
schemes are not suitable for HARTS. Hence, 
it supports fast switching methods such as 
virtual cut-through 7 and wormhole rout¬ 
ing. 8 In virtual cut-through, packets arriv¬ 
ing at an intermediate node are forwarded 
to the next node in the route without buff¬ 
ering if a circuit can be established to the 
next node. 

Kermani and Kleinrock did a mean-value 
analysis of virtual cut-through performance 
for a general interconnection network. 7 
However, a mean-value analysis is inade¬ 
quate for real-time applications because 
worst-case communication delays often play 
an important role in real-time system de¬ 
sign. A mean-value analysis cannot, for 
example, answer these questions: What is 
the probability of a successful delivery given 
a delay? What is the delay bound such that 
the probability of a successful delivery is 
greater than a specified threshold? 

Kermani and Kleinrock wanted to avoid 
any dependence on the interconnection 
topology in their analysis. As a result, they 
assumed that the probability of packet 
buffering at an intermediate node is a given 
parameter. Since a reasonable estimate of 
virtual cut-through performance cannot be 
obtained without an accurate estimate of 
buffering probability, their approach be¬ 
comes useful only if one can accurately 
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determine buffering probability for a given 
interconnection topology. This determina¬ 
tion is not a simple matter, because each 
node in a distributed system handles not 
only all packets generated at the node, but 
also all packets passing through the node 
(transit packets). Consequently, to evalu¬ 
ate the probability of buffering, we have to 
account for the fraction of packets gener¬ 
ated at other nodes that pass through each 
given node. 

In contrast to Kermani and Kleinrock, 
we first derive the probability that a packet 
is destined for a particular node by char¬ 
acterizing the H-mesh topology. We use 
this probability of branching as a parame¬ 
ter in a queueing network to determine the 
throughput rate at each node in the mesh. 
Once the throughput rates are found, we 
can derive the probability that a packet can 
establish a cut-through at an intermediate 
node. From these parameters, we finally 
derive the probability distribution function 
of delivery times for a packet traversing a 
specified number of hops. 

Figure 6 plots the inverse of the proba¬ 
bility distribution function for a message 
traveling five hops. The three curves show 
the variation in the inverse of the probability 
distribution function for different message- 
generation rates or network traffic. These 
curves are useful in determining design 
parameters such as delay bounds. For ex¬ 
ample, one can select a delay bound such 
that the probability of message delivery 


within that bound is greater than a speci¬ 
fied threshold. This would provide a prob¬ 
abilistic measure on the guarantees provided 
for real-time system operation. 

In contrast to the analytic model, a sim¬ 
ulator makes very few simplifying as¬ 
sumptions in modeling the behavior of 
virtual cut-through in HARTS. The simu¬ 
lator accurately models the delivery of each 
message by emulating the timing of the 
routing hardware along the packet route at 
the microcode level. It also captures the 
internal bus access overheads that the 
packets experience if they are unable to cut 
through an intermediate node. The simu¬ 
lator’s detailed timing and tracking of 
messages allows investigation of various 
message scheduling strategies, access 
protocols, and memory management strat¬ 
egies. The simulator can also use any dis¬ 
crete distribution of packet lengths for which 
the user specifies the number, length, and 
probability ofthe different types of message. 
The simulator has been used to check the 
validity of analytic models by evaluating 
the HARTS communication subsystem 
under various realistic settings. 

Evaluation of hybrid routing schemes. 

The basic idea of wormhole routing is that if 
a channel is not available, a message waits 
for it. Because the message is not removed 
from the network, it retains all resources 
from its source to the node at which it is 
waiting. Wormhole routing can be thought 


of as incrementally establishing a route be¬ 
cause it does not surrender the resources it 
has acquired along the path from source to 
destination. One benefit is that the message 
need not reacquire resources once it has 
acquired them. Deadlock-free algorithms 
based on wormhole routing have been pro¬ 
posed by Dally and Seitz. 8 

Virtual cut-through differs from worm- 
hole routing in that it stores the message at 
the node where it is blocked and releases 
the resources acquired on the path from the 
source to the blocking node once the 
message has been stored. 

The advantage of both wormhole routing 
and circuit switching is that they guarantee 
delivery once a source-to-destination con¬ 
nection has been established. Virtual cut- 
through, however, can lower latency when 
the hogging of links due to wormhole routing 
and circuit switching worsens the conges¬ 
tion in the network. 

To show the difference in performance 
of wormhole routing and virtual cut-through 
switching, we plotted their message laten¬ 
cies in Figure 7. For low traffic loads, 
wormhole routing takes less time on average 
to deliver messages; the opposite is true for 
high loads. The traffic load break-even 
point decreases as mesh size increases, 
because the average message distance in¬ 
creases with mesh size. Which routing 
method is more advantageous depends on 
the traffic load and average message dis¬ 
tance. The routing controller described 
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earlier has the flexibility to dynamically 
select the better of the two methods. 

Fault-tolerant routing 

One attractive feature of point-to-point 
networks is their ability to withstand link 
and node failures. Exploiting this feature 
requires developing algorithms and pro¬ 
viding mechanisms that preserve network 
communication in the presence of compo¬ 
nent failures. In this context, one must 
address correct routing of messages when 
one or more mesh components fail. This is 
of particular importance when the mesh is 
large and component failures thus are more 
likely, and when the system is expected to 
operate for long periods without mainte¬ 
nance. The ideal fault-tolerant routing al¬ 
gorithm would route messages by the 
shortest fault-free path, would require no 
extra hardware, would not cause unneces¬ 
sary delays at intermediate nodes, and would 
quickly determine whether a destination 
was unreachable. The algorithm presented 
by Olson and Shin 4 comes close to meeting 
these criteria and requires each node to 
know only the condition (faulty or non- 
faulty) of its own links. 

Each node of an H-mesh can be seen as 
the convergence point of three axes, and 
the shortest path between two nodes can be 
expressed as offsets along no more than 
two of the three axes. Since each of the six 
links represents movement along one of 
these three axes, either in the positive or 
negative direction, fault-free routing can 
be accomplished by forwarding messages 
along links that will bring them toward 
zero. Our idea is to not interfere with this 
process until the message finds its path 
blocked. A message is routed by the fault- 
free algorithm until it reaches a node where 
all the links through which the message 
would ordinarily be forwarded (called the 
optimal links) are faulty. At that point the 
fault-tolerant algorithm intervenes. 

At the point of message detouring, rout¬ 
ing control is split between the fault-free 
algorithm and the fault-tolerant algorithm. 
A single bit in the message header deter¬ 
mines which algorithm is currently making 
routing decisions. If this bit is clear, the 
message is in free mode, and the fault-free 
algorithm does the routing. Otherwise, the 
message is in detour mode, and the fault- 
tolerant algorithm does the routing. The 
fault-tolerant algorithm remains in control 
until it believes it has bypassed the faults 
that blocked the message path. 

The fault-tolerant algorithm can be 


viewed as a simple wall-following algo¬ 
rithm. The message travels around the edge 
of a cluster of faults until it reaches the other 
side. Implementation is simple. When the 
optimal links are found to be faulty, the 
message is placed in detour mode, and the 
NP looks for nonfaulty links, starting with 
the link immediately counterclockwise of 
the optimal links and proceeding counter¬ 
clockwise. The message is sent out on the 
first nonfaulty link found. If a message 
arrives at a node already in detour mode, it 
is sent out on the first nonfaulty link coun¬ 
terclockwise of the link by which it arrived. 
While in detour mode, the offsets to the 
destination are continually recalculated, and 
the message leaves detour mode when the 
distance to the destination is less than it was 
when the message entered detour mode. 

As an example, consider the situation in 
Figure 8. A message has arrived at node 18, 
with node 1 as its eventual destination. At 
18 the only optimal link is the one to node 0, 
which has failed; the message is placed in 
detour mode and sent to node 7. At 7 the 
fault-tolerant algorithm first tries to send 
the message to node 0, then to node 8, but 
finally must send it to node 15. At 15 the 
message is immediately forwarded to node 
8. At 8 the message returns to free mode as 
node 8 is closer to node 1 than node 18 is. 
The message then completes routing nor¬ 
mally. 

An unreachable destination is revealed 
by the presence of a cycle. If the fault- 
tolerant algorithm cannot get the message to 
the destination, the message will cycle. 
Unfortunately, for certain classes of fault 
configurations, called incisions, the mes¬ 
sage will cycle even though the destination 
is reachable. Simulation results show that 
this type of fault is rare, occurring only with 
large numbers of faults. It can be dealt with 
at a cost of increased complexity in the 
routing algorithm. Strategies for detecting 
and routing in the presence of incisions are 
outlined by Olson and Shin. 4 They show 
that the H-mesh is extremely robust: If 50 
percent of the links in an H } are faulty, a 
randomly chosen destination is reachable 
with probability greater than 0.95. 

Clock synchronization 

Widely recognized as one of the important 
requirements of a distributed real-time 
system, a global time base simplifies the 
solutions to design problems such as 
checkpointing, interprocess communica¬ 
tion, and resource allocation. 9 

Central to the establishment of a global 


time base is the synchronization of the local 
clocks on different nodes in the system. 
Both hardware and software solutions to 
this problem have been proposed. The soft¬ 
ware solutions are flexible and economical 
but require the exchange of additional 
messages solely for synchronization. 10 The 
overhead imposed by these additional mes¬ 
sages could be substantial, especially if a 
tight synchronization between processes is 
desired. Hardware solutions, on the other 
hand, require additional hardware at each 
node of the distributed system. They can 
achieve very tight synchronization between 
processes, with very little time overhead, 
but they require a separate network of clocks 
that is usually different from the network 
between the nodes. 

For HARTS, we use a software solution 
that requires minimal hardware support at 
each node. 11 It is based on the interactive 
convergence algorithm given by Lamport 
and Melliar-Smith. 10 (Note, however, that 
any other software clock synchronization 
algorithm can be used for our scheme.) The 
algorithm assumes that the clocks drift 
apart only by a bounded amount during 
each resynchronization interval, R , during 
which each process reads the value of ev¬ 
ery process’s clock. If the value of a clock 
read differs from its own clock by an amount 
greater than a threshold, the process re¬ 
places that value with its own clock value. 
The process then computes the average of 
all such values and sets its own clock to this 
average. Lamport and Melliar-Smith show 
that this algorithm can achieve synchroni¬ 
zation and requires 3/n+l processors to 
tolerate m faults. 

Three major problems arise when this 
algorithm is used in a distributed system 
with a point-to-point interconnection net¬ 
work. First, it is difficult for a process to 
read the clock of a process to which it is not 
directly connected. Second, the message 
received by a process may be corrupted by 
a faulty intermediate process. Third, a 
queueing delay for the clock messages may 
cause a substantial difference between the 
real times at which a clock value is sent and 
received. Therefore, subtracting the clock 
value in the received message from the 
current clock value will not reflect the 
actual skew between the clocks of the 
sending and receiving processes. This 
problem is aggravated when the clock mes¬ 
sage must pass through multiple interme¬ 
diate nodes. 

Ramanathan, Kandlur, and Shin 11 solve 
the first problem by letting each process 
broadcast its clock to all processes at a 
specified time, with respect to its own local 
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Figure 8. Example of fault-tolerant routing. 


clock, in the resynchronization interval. 
The second problem is eliminated by a 
broadcast algorithm that delivers multiple 
copies of the message to all processes 
through node-disjoint paths. For the third 
problem, it is not the size of the delay, but 
the fact that it is not known, that affects the 
clock skew. The message delivery time for 
clock messages is obtained by requiring 
each intermediate process to append to the 
message the delay incurred at that process. 

The accurate computation of this delay 
needs some hardware support. There is 
some uncertainty in determining time of 
receipt because of a variable delay be¬ 
tween the processor’s receiving notifica¬ 
tion of arrival and actually “seeing” the 
message. Also, to compute the time delay 
within the node, the processor must have 
control on the exact time at which a mes¬ 
sage is transmitted on a link. These poten¬ 
tial errors in estimating the time delay limit 
the accuracy with which we can compute 
the clock skew. This in turn affects the 
clock skew achievable with the synchroni¬ 
zation. 

To alleviate this problem, we use a hard¬ 
ware time-stamping mechanism at the link 
level for clock messages (see earlier sec¬ 
tion on the packet controller). When a link 
receiver detects a clock message, it ap¬ 
pends a receive time stamp to the message. 
Similarly, when a clock message is trans¬ 
mitted, the link transmitter appends a 
transmit time stamp. At an intermediate 
node, the receive and transmit time stamps 
use the same local clock, so their differ¬ 
ence gives a very accurate estimate of mes¬ 
sage time in that node. By computing the 
difference at intermediate nodes, we can 
keep the total number of time stamps down 


Figure 9. I/O controller placement. 


to five and prevent message length from 
growing as network size increases. 

For any synchronization algorithm, R is 
a function of the maximum clock skew 
desired. R decreases with the desired max¬ 
imum skew and becomes negative for small 
values. From a practical viewpoint, over¬ 
heads for the synchronization algorithm 
increase as R decreases, so it is desirable to 
have R as large as possible. This function 
effectively determines the type of skew 
that can be achieved for the system with a 
particular synchronization algorithm. The 
derivation of this function for the synchro¬ 
nization algorithm described here is given 
by Ramanathan, Kandlur, and Shin. 11 
This algorithm can achieve moderately 
tight synchronization. For example, in an 
H 3 , a maximum clock skew of 100 micro¬ 
seconds can be achieved using R= 6.23 
seconds. 

I/O architecture 

Most work on distributed computing 
systems has centered on interconnection 
networks, programming and communica¬ 
tions paradigms, and algorithms. Howev¬ 
er, little has been done specifically about 
the I/O subsystem in a real-time environ¬ 
ment, despite its obvious importance. 
Clearly, a real-time computer can process 
data no faster than it can acquire the data 
from sensors and operators. Note that I/O 
devices in a real-time environment are sen¬ 
sors, actuators, and displays, whereas they 
are magnetic disks and tapes for general- 
purpose systems. Due to the distinct timing 
and reliability requirements of real-time 
applications, solutions suited to general- 


purpose systems are not usually applicable 
to the real-time environment. 

To avoid the accessibility problems of 
nondistributed I/O, I/O devices need to be 
distributed and managed by relatively sim¬ 
ple, and reliable, controllers. Moreover, to 
improve both accessibility (and thus reli¬ 
ability) and performance, there must be 
multiple access paths (called multiaccessi¬ 
bility or multiownership) to these I/O de- 


I/O interconnection architecture. I/O 

devices are clustered, and a controller 
manages access to the devices of each 
cluster. The I/O controller (IOC) can be 
simple since HARTS uses simple data links 
to the computation nodes. The IOC need 
only handle sending and receiving simple 
messages via a set of full-duplex links, not 
providing virtual cut-through capabilities 
and other features of a full-blown NP. To 
keep the IOCs and the I/O links down to a 
reasonable number, the number of IOCs is 
restricted to no greater than the total num¬ 
ber (p) of computation nodes in the mesh. 
This has certain benefits for one of the 
management protocols explained later. 

Having established the potential number 
of I/O nodes, we need to decide how many 
nodes each IOC will be connected to. If the 
maximum number ( p ) of IOCs are assumed 
to exist in an H 3 , for example, then Figure 
9 shows a logical connection scheme. 12 
Each IOC can be thought of as being in the 
center of one of the upward-pointing trian¬ 
gles in this figure; the IOC is connected to 
each of the nodes that make up the triangle, 
called its left, right, and upper partners. 
This gives three possible avenues of access 
to each IOC. Note that if the maximum 
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number of IOCs are used, the number of 
I/O links required is equal to the number of 
standard communication links, or 9e2-9e+3 
for an H e . One could similarly place IOCs 
at the (logical) center of the downward¬ 
pointing triangles as well, allowing for up 
to 2 p IOCs, but this would double the 
maximum possible number of I/O links 
required and disturb certain homogeneous 
effects of limiting the number of IOCs to 
the number of nodes. 

Management protocols. The desire for 
simple I/O controllers presents a problem 
in HARTS, because the natural tendency 
would be to assign sensors and actuators, 
both relatively complex and expensive de¬ 
vices, to individual nodes or NPs and use 
the given interprocess communication (IPC) 
channels in HARTS to handle the I/O traf¬ 
fic. We can still use the given IPC channels, 
but instead of permanently tying down a 
given I/O device to one node, we allow 
several nodes to communicate with each 
I/O device. There are two fundamentally 
different protocols for managing this com¬ 
munication. 

The first management protocol, the stat¬ 
ic protocol, assigns one node to each IOC 
as its owner, but with the important provi¬ 
sion that the owner can be changed if the 
original owner becomes faulty. In this pro¬ 
tocol', one of the IOC links is defined as the 


active link, and the rest remain inactive as 
spares. The second, dynamic protocol, al¬ 
lows the IOC owner to be defined dynam¬ 
ically, providing greater accessibility and 
requiring fewer hops on average to reach 
the IOC owner. In this protocol, the IOC 
decides which link will be active at any 
given time. 

Figure 10 is an example in which a 
process in node 13 wants service from IOC 
18, but since node 18 is the owner under the 
static protocol and is not reachable from 
13, it cannot obtain service. If node 0 were 
the owner instead of 18 — which is possi¬ 
ble under the dynamic protocol — it could 
be serviced. 

In addition to making IOCs accessible 
where static ownership would make them 
inaccessible, the dynamic protocol takes 
into account the fact that one partner may 
be closer to a node requesting service than 
the other partner. Since this protocol chooses 
the closest of the partners that respond, the 
I/O traffic may have fewer hops to travel. 
However, its disadvantages are that it is 
more difficult to implement and involves 
arbitration overhead after servicing each 
I/O request. It may also be undesirable 
because there is no single node through 
which all I/O requests will travel and which 
could perform some I/O management tasks. 
Shin and Dykema give a comparative 
analysis of these two protocols. 12 


A ll the high-level architectural is¬ 
sues of HARTS have been re¬ 
solved, and the lower-level com¬ 
ponents are being designed or implement¬ 
ed. The routing controller, a key compo¬ 
nent for fast switching, has been fabricat¬ 
ed, and its testing is almost complete. The 
packet controller, the second generation of 
the routing controller, and other NP com¬ 
ponents are currently being designed and 
simulated. In parallel with the architectur¬ 
al work, we are also designing and imple¬ 
menting a software communication sub¬ 
system for HARTS . The primary objectives 
of this subsystem are to deliver messages 
within certain deadline constraints, sup¬ 
port mechanisms for group communica¬ 
tion and reliable broadcasting, offer ser¬ 
vices such as maintenance of a global time 
base, and monitor system behavior. ■ 
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Real-Time-Systems 
Performance in the Presence 
of Failures 


Jogesh K. Muppala, Duke University 
Steven P. Woolet, IBM 
Kishor S. Trivedi, Duke University 


T he growing use of real-time sys¬ 
tems in such diverse areas as 
transaction processing, air-traffic 
control, process control, and mission-crit¬ 
ical control has created a need for effective 
analysis techniques to model these sys¬ 
tems. Real-time systems are characterized 
by stringent deadlines and high-through¬ 
put and high-reliability requirements. Tra¬ 
ditional analysis techniques, which rely 
mostly on mean values of the measures, 
cannot capture all the nuances of these 
systems. 

When analyzing a transaction process¬ 
ing system, we often wish to compute the 
response time for a transaction. A typical 
performance requirement for transaction 
processing systems is a 1-second response 
for at least 95 percent of the transactions 
(usually referred to as the 95th percentile). 
Because failure to meet the deadline re¬ 
sults in losses but may not be catastrophic, 
such systems are called soft real-time sys¬ 
tems. 

A mission-critical system is best charac¬ 
terized by how fast it can respond to a 
change in input stimuli or the environment. 
Typically we would require a guaranteed 
response within a short period of time com¬ 
monly referred to as a hard deadline. Thus, 
such systems are called hard real-time 
systems, since the consequences of failing 


This unified 
methodology for 
modeling real-time 
systems uses 
techniques that 
combine the effects of 
performance, 
reliability/availability, 
and deadline violation 
into a single model. 


to meet the deadline could be catastrophic. 
Here, it is important to know the probabil¬ 
ity that the response time will be less than 
the deadline; this implies that the response¬ 
time distribution must be computed. 

Queueing networks 1 have been used tra¬ 
ditionally to study the performance of 
computer systems. They are useful in rep¬ 
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resenting contention for resources, as oc¬ 
curs in transaction processing systems. 
Computing the response-time distribution 
for queueing networks using closed-form 
expressions is extremely difficult even for 
networks with a simple structure. 2 Nu¬ 
merical evaluation of the response-time 
distribution, however, is not difficult, as 
we will show. 

Failures and repairs of components in a 
real-time system can noticeably affect per¬ 
formance. Thus, any realistic system mod¬ 
el must also incorporate the effect of fail¬ 
ures and repairs. Meyer 3 introduced a useful 
framework called performability for com¬ 
bining performance and reliability. In this 
case, the performance levels can be incor¬ 
porated into the failure-repair model to 
study overall system behavior. When the 
failure-repair behavior is Markovian in 
nature, the approach results in a Markov 
reward model. 4 

Shin and Krishna 5 defined some inter¬ 
esting performance measures for hard real¬ 
time multiprocessor systems. Failure to 
meet a hard deadline is assumed to be 
catastrophic, leading to system failure. They 
compute the dynamic failure probability, 
taking into account hard-deadline failures. 
A cost function associated with the tasks in 
the model is used as an optimization crite¬ 
rion for designing real-time systems. Al- 
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Figure 1. Markov chain model used by 
Shin and Krishna. 


though Shin and Krishna’s performance 
measures are general, their example is re¬ 


stricted to a single-resource model. Their 
approach complements Meyer’s. 

In this article we present a unified meth¬ 
odology for modeling both soft and hard 
real-time systems, combining Meyer’s ap¬ 
proach with that of Shin and Krishna. We 
use an on-line transaction processing sys¬ 
tem as an example to illustrate our model¬ 
ing techniques. We consider dynamic fail¬ 
ures due to a transaction’s violating a hard 
deadline by incorporating additional tran¬ 
sitions in the Markov chain model of the 
failure-repair behavior, as described by 
Shin and Krishna. We also take into ac¬ 
count system performance in the various 
configurations by using throughput and 
response-time distribution as reward rates. 
Since the Markov chains used in comput¬ 


ing the distribution of response time are 
often very large and complex, we use a 
higher level interface based on a variation 
of stochastic Petri nets called stochastic 
reward nets. 6 

A motivating example 

Shin and Krishna present an interesting 
model for a real-time multiprocessor sys¬ 
tem incorporating hard-deadline failures. 
The performance of a multiprocessor sys¬ 
tem with m processors is modeled using an 
M/M/m queue with Poisson arrival of tasks 
at the rate X. The system’s initial configu¬ 
ration has IVprocessors. The processors are 
allowed to fail, and the time to failure of 


Markov chains and Markov reward models 


A Markov chain is a state-space-based method for modeling 
systems. It is composed of states, and transitions between 
states. The states of a Markov chain can be used to represent 
various entities associated with a system — for example, the 
number of functioning resources of each type, the number of 
tasks of each type waiting at a resource, the number of concur¬ 
rently executing tasks of a job, the allocation of resources to 
tasks, and states of recovery for each failed resource. A transi¬ 
tion represents the change of the system’s state due to the oc¬ 
currence of a simple or a compound event, such as the failure 
of one or more resources, the completion of executing tasks, or 
the arrival of jobs. A transition thus connects one state to an¬ 
other. 

A Markov chain is a special case of a discrete-state stochas¬ 
tic process in which the current state completely captures the 
past history pertaining to the system’s evolution. Markov chains 
can be classified into discrete-time Markov chains and continu¬ 
ous-time Markov chains, depending on whether the events can 
occur at fixed intervals or at any time — that is, whether the 
time variable associated with the system’s evolution is discrete 
or continuous. This article is restricted to continuous-time 
Markov chains. Further information on Markov chains is avail¬ 
able in the literature. 1 

In a graphical representation of a Markov chain, states are 
denoted by circles with meaningful labels attached. Transitions 
between states are represented by directed arcs drawn from 
the originating state to the destination state. Depending on 
whether the Markov chain is a discrete-time or a continuous¬ 
time Markov chain, either a probability or a rate is associated 
with a transition. 

To illustrate these concepts further, let’s consider an exam¬ 
ple based on a multiprocessor system comprising two dissimi¬ 
lar processors, PI and P2. When both processors are function¬ 
ing, the time to occurrence of a failure in processors PI and P2 
is assumed to be a random variable with the corresponding dis¬ 
tribution being exponential with rates y, and y 2 , respectively. 

We also consider a common-mode failure whereby both pro¬ 
cessors can fail simultaneously. The time to occurrence of this 
event is also assumed to be exponentially distributed with rate 


y c . When only one processor is functioning, the rate of failure 
could be correspondingly altered to reflect the fact that a single 
processor carries the load of both processors. When only PI is 
functioning, we assume its failure rate is y/, and when only P2 
is functioning, its failure rate is y 2 . We could consider repair of 
the processors where the time to repair the processors is also 
exponentially distributed with rates §! and 8 2 , respectively. We 
also assume that when both processors are waiting for repair, 
PI has priority over P2. 

The behavior of this system can be represented by a contin¬ 
uous-time Markov chain, shown in the figure in this sidebar. In 
this figure the label (/, J) of each state is determined as follows: 
/= 1 if PI is up, and 1=0 if PI is failed; similarly, j=0 or 1, de¬ 
pending on whether P2 is failed or up. Solving this Markov 
chain involves computing either Py(f), the probability of being 
in state (/, j) at time f, or n y , the steady-state probability of be¬ 
ing in state (/, j). 

Now let’s consider the formal notation for a Markov chain. 

Let {Z(t),t > 0} represent a homogeneous finite-state continu¬ 
ous-time Markov chain with state space £1. Typically, we are in¬ 
terested in computing P,(f), the unconditional probability that 
the continuous-time Markov chain will be in state / at time t. 

The corresponding row vector P(f) = [P,(f)] represents the 
transient state probability vector of the continuous-time Markov 
chain. Let tc, be the steady-state probability of state / of the 
continuous-time Markov chain. Then n = M is the correspond¬ 
ing steady-state probability vector. 

A Markov reward model is obtained by associating a reward 
rate r, with each state / of the continuous-time Markov chain. 

Let X(t) = />(,) be the random variable corresponding to the re¬ 
ward rate at time t. Then the expected reward rate E[X(f)j can 
be computed as follows: 


The expected reward rate in steady state can be computed as 
E[X] = E[XHJ = 5>,. 
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each processor is exponentially distributed 
with rate y. The system is assumed to be 
nonrepairable, and at least n processors are 
required for the system to be stable. Figure 
1 shows the corresponding Markov model. 
The hard deadline is assumed to be a ran¬ 
dom variable. To model hard-deadline 
failures, Shin and Krishna use additional 
transitions from each up state to the failure 
state. In this figure, h-, (n < i < AT) is the 
product of the task arrival rate and the 
probability that a task violates the hard 
deadline; that is, /z,=XJo°°[l - F MM f.t)]dFJit), 
where F MMi (t) is the response-time distri¬ 
bution of an M/M/i queue, and F d (t) is the 
cumulative distribution function of the 
random variable corresponding to the hard 
deadline. It is assumed that the queue is 


stable in state i, that is, A, < ip, where p. is 
the service rate of a single processor. 

For this example Shin and Krishna com¬ 
pute the dynamic failure probability, given 
by the instantaneous probability Pf(t), of 
state F. The dynamic failure probability is 
computed as a function of the number of 
processors as well as the number-power 
product (number of processors times the 
service rate of each processor). By defin¬ 
ing a cost function for this model, the mean 
cost over the mission’s lifetime was also 
computed. 

For the same example, we might want to 
compute the amount of work processed 
until hard-deadline failure. This can be 
done using Markov reward models. The 
probability that a job will violate the dead¬ 


line in state i has already been specified as 
lb°°[l - FMMi(t)]dF d (t). Thus, the rate of 
the arriving jobs that will meet the deadline 
in state i is given by A(l-J 0 °°[l- 
FMMi(t)]dF d (t)). This is the effective 
throughput of the system in state i. If we 
assign this as the reward rate in state i and 
compute £jT(r)], it yields the expected 
number of jobs completed successfully until 
time t, while £[K(“)j yields the expected 
number of jobs processed until hard-dead¬ 
line failure. 

Thus we see that combining Meyer’s 
work with that of Shin and Krishna makes 
possible the analysis of real-time fault- 
tolerant systems, so that we can consider 
different types of failures in a single mod¬ 
el. We can consider soft deadlines by 


where X is the random variable corresponding to the steady- 
state reward rate. For a detailed discussion of using Markov re¬ 
ward models for evaluating computer systems, see Smith, 
Trivedi, and Ramesh. 2 As an example, by assigning a reward 
rate of 1 to up states and 0 to failure states, E[X(f)] yields the 
instantaneous system availability and E[X] the steady-state 
system availability. Alternatively, we might wish to compute the 
accumulated reward Y(t) over the interval [0,f), where Y(t) is 
given by 

y(0 = J>(r)t#r = /V z , t ,cfT 

It is possible to compute the expected accumulated reward 
E[Y(t)] by using the following expression: 

ElYim^j'PMdr 

This lets us determine how much total work has been done by 
time t. We can also consider the time-averaged measure 
E[Y(t)/t], 

Computing the distribution of Y(t) is comparatively difficult. 2 
On the other hand, if we consider a system with absorbing fail¬ 
ure states, we could compute the distribution of accumulated 
reward until absorption, P[Y(°°)<y], using a technique pro¬ 
posed by Beaudry. 3 In this technique we divide each transition 
rate emanating from a state by the reward rate associated with 
that state. The distribution of time to absorption for this trans¬ 
formed Markov chain yields the distribution of Y(<*>) for the origi¬ 
nal Markov chain. 

The question remaining is, what constitutes an appropriate 
reward assignment? We saw earlier that binary reward assign¬ 
ment (0 and 1) yields traditional reliability/availability measures. 
We could assign the performance levels as reward rates. In the 
above example let’s assume that the service rate of the two 
processors PI and P2 is p, and p 2 , respectively. A capacity- 
based reward rate assignment so that r / y = / pi, + yp 2 yields the 
computational availability. 3 Alternatively, if we assume a more 
general structure for the performance model, we can compute 
the throughput in each system state. If we set r, t to be the sys¬ 


tem’s throughput in state /', j, then we can obtain the through¬ 
put-oriented availability. 4 
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combining throughput and response-time 
distributions into the reward rates, and 
we can consider dynamic failures due to 
deadline violations. Failure due to imper¬ 
fect coverage can also be modeled. The 
method applies to multiple-resource 
models as well. Nevertheless, for suc¬ 
cessful analysis, we must be able to gen¬ 
erate and solve large, complex Markov 
chains. In the next section we describe 
our method, using an example. 

We realize that we must compute the 
response-time distributions for tasks in a 
system with multiple resources. Comput¬ 
ing the response-time distribution in gen¬ 
eral is difficult. Closed-form expressions 


are available only for simple queueing 
systems. For networks of queues, numer¬ 
ical solution using Markov chains ap¬ 
pears to be the only possible method. To 
automatically generate and solve the 
Markov model for computing response¬ 
time distribution, we use stochastic Petri 
nets. Finally, the assignment of rewards 
to the failure-repair Markov model is es¬ 
sential to our approach. Thus, we must 
automatically generate reward rates for 
the Markov chain that is generated auto¬ 
matically from a stochastic Petri net. We 
use an extension of stochastic Petri nets, 
called stochastic reward nets, for this 
purpose. 


Modeling an on-line 
transaction processing 
system 


On-line transaction processing systems 
have become a major application area for 
computers. They are needed when many 
users require instant access to information 
such as records in large databases. Exam¬ 
ples; include airline reservation systems and 
automated bank-teller systems. These sys¬ 
tems are characterized by high-throughput 
and high-availability requirements. 

Figure 2 shows a typical architecture for 


Stochastic reward nets 

A stochastic reward net is an extension of a stochastic Petri 
net. The latter, in turn, is an extension of a Petri net. We will 
briefly introduce Petri nets and stochastic Petri nets and then 
describe some structural and stochastic extensions. 

Basic terminology. A Petri net is a bipartite diagraph whose 
nodes are divided into two disjoint sets called places and tran¬ 
sitions. Directed arcs in the graph connect places to transi¬ 
tions (input arcs) and transitions to places (output arcs). A mul¬ 
tiplicity may be associated with these arcs. A marked Petri net 
is obtained by associating tokens with places. Marking a Petri 
net means distributing tokens in its places. In a graphical rep¬ 
resentation of a Petri net, circles represent places, bars repre¬ 
sent transitions, and dots or integers in the places represent to¬ 
kens. Input places of a transition are the set of places that are 
connected to the transition through input arcs. Similarly, output 
places of a transition are those places connected to the transi¬ 
tion by output arcs. 

A transition is considered enabled in the current marking if 
the number of tokens in each input place is at least equal to 
the multiplicity of the input arc from that place. The firing of a 
transition is an atomic action in which one or more tokens are 
removed from each input place of the transition and one or 
more tokens are added to each output place of the transition, 
possibly resulting in a new marking of the Petri net. When the 
transition is fired, the number of tokens deposited in each of its 
output places is eqflal to the multiplicity of the output arc. Each 
distinct Petri net marking constitutes a separate state of the 
Petri net. A marking is reachable from another marking if there 
is a sequence of transition firings starting from the original 
marking that results in the new marking. The reachability set 
(graph) of a Petri net is the set (graph) of markings reachable 
from the other markings. In any Petri net marking, a number of 
transitions may be simultaneously enabled. 

Another type of arc in a Petri net is the inhibitor arc. An inhib¬ 
itor arc drawn from a place to a transition means that the tran¬ 
sition cannot fire if the place contains at least as many tokens 
as the multiplicity of the inhibitor arc. 

Extensions to Petri nets have been considered by associ¬ 
ating firing times with the transitions. By assuming the firing 


times of the transitions to be exponentially distributed, we 
get the stochastic Petri net. The underlying reachability 
graph of a stochastic Petri net is isomorphic to a continuous¬ 
time Markov chain. Further generalization of stochastic Petri 
nets has been introduced by Marsan et al., 1 allowing transi¬ 
tions to have either zero firing times (immediate transitions) 
or exponentially distributed firing times (timed transitions), in 
turn giving rise to the generalized stochastic Petri net. In the 
figures accompanying this article, hollow rectangles repre¬ 
sent timed transitions, while thin bars represent immediate 
transitions. The markings of a generalized stochastic Petri 
net are of two types: A marking is vanishing if only immedi¬ 
ate transitions are enabled in the marking and tangible if 
only timed transitions or no transitions are enabled in the 
marking. Conflicts among immediate transitions in a vanish¬ 
ing marking are resolved using a random switch. 1 

Structural extensions. Ciardo et al. 2 introduced several 
structural extensions to Petri nets that increased their modeling 
power. These include enabling functions, general marking de¬ 
pendency, and variable cardinality arcs. 

Enabling function. A Boolean enabling function E(.) is associ¬ 
ated with each transition. Whenever a transition satisfies all the 
input and inhibitor conditions in a marking M (that is, when the 
input places contain enough tokens to enable the transition, 
and the number of tokens in the inhibitor places is less than the j 
multiplicity of the corresponding inhibitor arc), the enabling 
function is evaluated. The transition is considered enabled only 
if the enabling function E(M) = true. Enabling functions are 
very useful in expressing complex interdependencies, simplify¬ 
ing the model structure, and implementing state truncation. 

Variable cardinality arc. The multiplicity of an arc in a Petri 
net can be defined as a function of the Petri net marking. This 
facility is useful in simplifying the Petri net’s structure. It is es¬ 
pecially useful if an input place needs to be flushed. This facili¬ 
ty can be used with input arcs, output arcs, and inhibitor arcs. 

Marking dependency. The rates and probabilities of transi- 
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an on-line transaction processing system. 
The system’s front end comprises a trans¬ 
action generator—a terminal or a bar code 
reader — and transaction processors that 
analyze the submitted transaction to deter¬ 
mine the information needed from the da¬ 
tabases and to provide error recovery ca¬ 
pabilities. The system’s back end consists 
of a set of database processors that read and 
update the records in the databases accord¬ 
ing to the requests submitted by the trans¬ 
action processors. The transactions visit 
the transaction processors and database 
processors in succession until the neces¬ 
sary processing is completed. Thus, a good 
measure of performance for an on-line 
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Figure 2. Architecture of an on-line transaction processing system. 


tions can also be defined as general functions of the marking of a 
stochastic Petri net. This would be very useful in modeling a multi¬ 
ple-server queue, for example. 

Stochastic extensions. We are interested in automatically gen¬ 
erating Markov reward models. For this purpose stochastic Petri 
nets have been extended by associating reward rates with the 
markings to obtain stochastic reward nets. 2 The reward rate defini¬ 
tions are specified at the net level as a function of net primitives, 
such as the number of tokens in a place or the rate of a transition. 
For each marking of the net, the reward rate function is evaluated 
and the result is assigned as the reward rate for that marking. The 
underlying Markov model is then transformed into a Markov re¬ 
ward model, thus permitting evaluation of performance and avail¬ 
ability both separately and in combination. We associate a reward 
rate r, with every tangible marking /'. Since the probability of being 
in a vanishing marking is zero, there is no need to assign reward 
rates to vanishing markings. We can then compute E[X], the ex¬ 
pected steady-state reward rate; E[X(f)], the expected instanta¬ 
neous reward rate; E[Y{I )], the expected value of the accumulat¬ 
ed reward; E[Y(°°)], the mean of the accumulated reward until 
absorption; and P[/(~) < y], the distribution of the accumulated 
reward until absorption. 

Note that the definition of reward rates is orthogonal to the anal¬ 
ysis type used. Thus, with the same reward definition we can com¬ 
pute the steady-state expected reward rate as well as the instanta¬ 
neous reward rate at time t, the expected accumulated reward, 
and the expected time-averaged reward over the interval [0,f). 

The figure in this sidebar shows the stochastic reward net model 
corresponding to the two-processor example considered earlier. In 
this figure timed transitions tlfl, t2fl, and tcfl represent the failure 
of processors PI and P2, and the common-mode failure, respec¬ 
tively. Transitions tlrp and t2rp represent the repair of the two pro¬ 
cessors. The inhibitor arc from place pldn to transition t2rp imple¬ 
ments the repair priority of PI over P2. The firing rates of 
transitions tlfl and t2fl are marking dependent, as shown in the 
figure. We see that when processor P2 is up, that is, when place 
p2up contains a token, the firing rate of tlfl is y.|. However, when 
P2 has failed, that is, when place p2up is empty, the firing rate is 
y{. The rate function for transition t2fl is similarly defined. 
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Figure 3. Closed queueing network model of the on-line transaction processing 
system. 
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Figure 4. Stochastic reward net model for computing the response-time distribu¬ 
tion. 


transaction processing system is the re¬ 
sponse time of a transaction. 

Next we model various aspects of the 
on-line transaction processing system, in¬ 
cluding the response-time distribution for 
a transaction and the effects of soft-dead- 
line and hard-deadline failures. 

Response-time distributions. The per¬ 
formance of the on-line transaction pro¬ 
cessing system can be studied using the 
queueing network model shown in Figure 
3, since the system involves contention for 
resources. In this model it is assumed that 
the transaction processors share a single 
queue from which transactions are selected 
for processing using a scheduling discipline 
that satisfies product-form assumptions. 1 

The transaction processors are modeled 
using a multiserver queue with the number 
of servers equal to the number of transac¬ 
tion processors. The database processors 
are similarly configured. The service times 
of the transaction processors are exponen¬ 
tially distributed with mean l/p TP ; the 
service times of the database processors 
are also exponentially distributed with mean 
1/Pdbp- The average time between comple¬ 
tion of a transaction and submission of the 
next transaction at a terminal (equivalent 
to the “think time” at the terminal) is also 
exponentially distributed with mean 1/A,. 

The number of terminals available in the 
system is assumed to be N. A transaction 
completing execution at the transaction 
processor may visit the database processor 
with probability p 0 or complete execution 
and return to the terminals with probability 
1 -p 0 . Since this queueing network obeys 
product-form assumptions, we could use 
efficient algorithms such as mean value 
analysis 1 to compute such steady-state per¬ 
formance measures as average throughput, 
average queue length at each queue, and 
average response time for a transaction. 
Given that there are i transaction proces¬ 
sors and j database processors in the system, 
we can compute the average system 
throughput Tjj. This measure gives the av¬ 
erage number of transactions completing 
in a unit time. 

Although computing the averages of 
various performance measures is easy, this 
does not present the complete picture, es¬ 
pecially with respect to on-line transaction 
processing systems. It then becomes nec¬ 
essary to evaluate the response-time distri¬ 
butions to obtain the percentiles. Comput¬ 
ing response-time distributions for a 
queueing network with arbitrary structure 
is very difficult. Closed-form solutions are 
available for only a small subset of queue- 
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Figure 5. Stochastic reward net model of the closed queueing network. 


ing networks. 2 However, it is possible to 
numerically evaluate the response-time 
distributions using the tagged-customer 
approach. 7 In this method a target custom¬ 
er is chosen whose movement through the 
network is observed to compute the re¬ 
sponse-time distribution. We also adopt 
the tagged-customer approach to numeri¬ 
cally evaluate the response-time distribu¬ 
tion for the on-line transaction processing 
system. We will assume a first come, first 
served service discipline at the transaction 
processor queue and database processor 
queue. The method can be easily extended 
to other service disciplines. 

The stochastic reward net shown in Fig¬ 
ure 4 is used to implement the tagged- 
customer approach. In the figure, #(p) rep¬ 
resents the number of tokens in place p, and 
# associated with a transition means that its 
service rate is marking dependent. 

Let’s look at how the position of the 
tagged customer is tracked through the 
network. In the figure the places ptpqo, 
ptpq, and pttpq and the transitions tpoi, ttp, 
and tttp together implement the multiserv¬ 
er first come, first served queue corre¬ 
sponding to the transaction processors. 
When the tagged customer is in the queue, 
all customers ahead of it are represented by 
the tokens in place ptpq (for convenience 
we can call this place the inner queue), and 
customers behind the tagged customer are 
in place ptpqo (we can refer to this place as 
the catchment area). The tagged customer 
will be scheduled for service only when the 
number of customers ahead becomes less 
than the number of transaction processors. 
This procedure is implemented by the en¬ 
abling function controlling the firing of 
transition tttp. All customers arriving after 
the tagged customer are deposited in place 
ptpqo. Whenever a transaction processor 
becomes available and the tagged customer 
is already in service, another customer can 
be admitted to the inner queue from the 
catchment area and scheduled for service. 
This is implemented by allowing the tran¬ 
sition tpoi to fire, taking one token out of 
ptpqo and depositing a token in ptpq. If the 
tagged customer is not in the queue, an 
arriving customer can proceed directly from 
the catchment area to the inner queue. This 
complex structure is implemented using 
the variable arc function defined in Figure 
4. A similar structure is used for the data¬ 
base processor queue. 

Since this is a closed product-form net¬ 
work, by applying the Sevcik-Mitrani 
(Lavenberg-Reiser) arrival theorem, 1 ’ 8 we 
know that an arriving customer sees the 
network in equilibrium with one less cus¬ 


tomer; that is, if we are evaluating the 
system with N customers, the tagged cus¬ 
tomer sees the network in equilibrium with 
N - 1 customers. When the tagged custom¬ 
er arrives at the transaction processor queue, 
it sees the network in equilibrium with i 
customers in the transaction processor 
queue, j customers in the database proces¬ 
sor queue, and the remaining N-(i+j + 1) 
customers at the terminals. Thus, the steady- 
state probabilities for all the states (i,j, N - 
(i +j + 1)), where 0 < i,j < N- 1, are 
needed. These probabilities can be calcu¬ 
lated by solving the stochastic reward net 
shown in Figure 5 with N- 1 customers. 

Figure 5 represents a stochastic reward 
net model of the queueing network corre¬ 
sponding to the on-line transaction pro¬ 
cessing system. In this network, places 
ptpq and pdbpq represent the queues for 
the transaction processors and database 
processors, respectively. Place pterm rep¬ 
resents the terminals. Transitions ttp and 
tdbp represent the service time at the trans¬ 
action processors and database processors, 
respectively, and transition tterm corre¬ 
sponds to the think time at the terminals. 
Routing of the customer to the database 
processor or the terminal upon completion 
of service at the transaction processor is 
implemented by place pbrch and transi¬ 
tions tpd and tpt, respectively. 

The response-time distribution is com¬ 
puted as the expected instantaneous re¬ 
ward rate E [X(t)\ by associating a reward 
rate of 1 with those markings where place 
ptfin is nonempty and a reward rate of 0 for 
all other markings. The mean time to ab¬ 
sorption (token appearing in place ptfin) 
gives the mean response time for the 
queueing network. This has been used to 
validate the stochastic reward net model. 


since the mean response time can be com¬ 
puted using other product-form solution 
methods like mean value analysis or con¬ 
volution. 1 

The response-time distribution P[R < I] 
for various configurations is shown in Fig¬ 
ure 6 (the label [T, D\ represents the num¬ 
ber of transaction processors and the number 
of database processors, respectively). For 
this example we set X = 1.0 per second, |i XP 
= 50.0 per second, p DBP = 20.0 per second, 
and p 0 = 0.8. We assume that the number 
of transaction processors is equal to the 
number of database processors. We also 
assume that with every additional transac¬ 
tion processor, the number of terminals 
increases by five. Note that the response 
time decreases with an increase in the 
number of processors even if the number of 
terminals is correspondingly increased. 
Table 1 shows the size of the Markov 
chains and the number of arcs in the Markov 
chain for each case. The maximum size of 
solvable problems is limited by the amount 
of memory available on the computer and 
not by the method. 

Modeling soft- and hard-deadline 
failures. Earlier we showed a method for 
computing the response-time distribution 
for a transaction. In characterizing real¬ 
time systems, we often wish to compute 
the probability that a transaction will fail to 
meet a deadline. As stated earlier, a typical 
requirement for a transaction processing 
system is for 95 percent of the transactions 
to complete within a second. This 
is often characterized by the deadline vio¬ 
lation probabilities, which in turn can be 
easily computed from the response-time 
distribution. Failure to meet a deadline can 
be due to several reasons. Resources avail- 
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Figure 6. Response-time distribution for the on-line transaction processing 

system. 


Table 1. Sizes of the Markov chains for different configurations. 


No. of 

TPs/DBPs 

No. of 

Terminals 

No. of 

States 

No. of 

Arcs 

1 

5 

85 

205 

2 

10 

405 

1,305 

3 

15 

1,088 

3,722 

4 

20 

2,262 

7,998 

8 

40 

14,428 

53,932 
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Figure 7. Failure-repair behavior of the transaction processors and the database 
processors. 


able in a system are subject to failure and 
repair. Transactions may face inordinate 
delays, or, in the worst case, be rejected if 
the system is unavailable when they arrive. 
Even if a fault-free system provides satis¬ 
factory service, a degraded configuration 
may not. Depending on the nature of the 
system, soft or hard deadlines may best 
describe its behavior. 

Now let’s consider the performance of 
the on-line transaction processing system 
in the presence of resource failures and 
repairs. We will assume that only the pro¬ 
cessors are subject to faults and the re¬ 
maining system, including the intercon¬ 
nection networks and the communication 
medium, is fault free. This is a reasonable 
assumption, since failure rates for the rest 
of the components are much lower than 
those of the processors. We consider both 
soft- and hard-deadline violations with the 
implicit assumption that a hard-deadline 
violation is catastrophic. 

The failure-repair behavior of the trans¬ 
action processors and the database pro¬ 
cessors is modeled by the stochastic reward 
net model shown in Figure 7. In this model 
we assume that the failed transaction pro¬ 
cessors and database processors share a 
single repair facility. When both types of 
processors fail, priority for repair is given 
to whichever type has the most failures. 
When an equal number of transaction pro¬ 
cessors and database processors fail, 
transaction processors get a higher priori¬ 
ty. This is reflected by the enabling func¬ 
tions shown in the figure. The times to 
failure for the transaction processors and 
database processors are exponentially dis¬ 
tributed with rates y T and Yd> respectively. 
The corresponding repair times are also 
exponentially distributed with rates p T and 
P D , respectively. 

We assume that transactions in the sys¬ 
tem must meet a fixed deadline x. First the 
soft-deadline case is considered. We as¬ 
sume that violation of the soft deadline 
results in the transaction’s being aborted. 
The system continues to function, howev¬ 
er. We will assign a reward rate of 
TjjP[Rij <x] to the stochastic reward net 
marking having i tokens in place puptp and 
j tokens in place pupdbp. Here, T t j is the 
throughput of the on-line transaction pro¬ 
cessing system with i transaction proces¬ 
sors and j database processors, and P[Ry < x] 
is the probability that the response time is 
less than x. The reward rate assigned cor¬ 
responds to the average number of trans¬ 
actions completing in a unit time that meet 
the deadline. 

We assume implicitly that whenever a 
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Figure 8. Failure-repair behavior with hard-deadline fail¬ 
ures. 


Figure 9. Markov chain of failure-repair behavior for a 2 x 
2 system. 


transaction arrives while the system is in a 
particular configuration with i transaction 
processors and j database processors, it will 
complete in the same configuration. This is 
a reasonable assumption, since failure rates 
for the processors are very small. Thus, 
from the viewpoint of a transaction, the 
system is assumed to be in a quasi-stable 
state. Shin and Krishna used a similar as¬ 
sumption. 5 

If we consider the deadline to be hard, 
then we assume that the system will fail if 
this deadline is violated. In this case the 
system’s failure-repair behavior is modi¬ 
fied, as shown in Figure 8. In this figure the 
failure rate of the transition thdfail is set to 
T i jP[R ij > t] — the rate at which transac¬ 
tions fail to meet the deadline. This is 
analogous to the failure rate for the hard- 
deadline violation considered by Shin and 
Krishna. Note, however, that we have con¬ 
sidered a fixed deadline. This procedure 
can be extended easily to a case in which 
the deadline itself is a random variable, as 


with Shin and Krishna. They considered 
an open queueing system, so the through¬ 
put was configuration independent (equal 
to X). The response-time distribution was 
available as a closed-form expression for 
the simple queue they considered, whereas 
the response-time distribution had to be 
computed numerically for our queueing 
system. In Figure 9 we show the failure- 
repair Markov chain (structure-state pro¬ 
cess) corresponding to a system with two 
transaction processors and two database 
processors. This Markov chain corresponds 
to a case in which hard-deadline failures 
are considered. States (2,0), (1,0), (0,1), 
and (0,2) are considered system down states. 
The reward rates assigned to the Markov 
chain states are also shown explicitly. 

We consider various measures to char¬ 
acterize the on-line transaction processing 
system in the presence of failures and re¬ 
pairs. In our numerical example, we con¬ 
sider a system with four transaction pro¬ 
cessors and four database processors. The 


failure rate for the processors is assumed to 
be 0.01 per hour; the repair rate is 2 per 
hour. Figure 10 shows a plot of the expect¬ 
ed time-averaged sy stem throughput E [ Y(t)l 
t\ as a function of time for both the soft- and 
hard-deadline cases, where we plot the 
cases when the deadline T is 1 and 2 sec¬ 
onds. As a comparison, we also plot the 
expected time-averaged throughput for the 
system with no deadlines. This represents 
the upper bound on the overall system 
throughput that can be achieved. From the 
figure, we notice that as the deadline is 
relaxed, the throughputs for the systems 
with deadlines move closer to this upper 
bound. As expected, the system with soft 
deadlines outperforms the system with hard 
deadlines, since a hard-deadline violation 
is catastrophic. 

Figure 11 plots the probability of system 
failure, P SF (f), as a function of time for 
both soft- and hard-deadline cases for a 
system with four transaction processors 
and four database processors. In this exam- 
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Figure 10. Throughput with deadlines as a function of time. 


pie we consider as absorbing states those 
(static failure) states in which all the 
transaction processors or all the database 
processors have failed. The figure shows 
that hard-deadline failure (dynamic fail¬ 
ure) is the leading cause of system failure. 

In Figure 12 we plot the distribution of 
number of tasks successfully completed 
until absorption for both the soft- and 
hard-deadline cases for a system with four 
transaction processors and four database 
processors. The figure shows that the 
probability of failing to accumulate re¬ 
ward y for the hard-deadline case is much 
higher than for the soft-deadline case. 
This is to be expected, since hard-deadline 
failures are catastrophic. 



Time t in hours 


Figure 11. Unreliability as a function of time. 



y 


Figure 12. Distribution of number of tasks successfully completed until 
absorption. 


W e have presented some inter¬ 
esting techniques for evaluat¬ 
ing real-time systems. These 
techniques combine the effects of perfor¬ 
mance, reliability/availability, and dead¬ 
line violation into a single model. We use 
a numerical method for computing the re¬ 
sponse-time distribution for a queueing 
network. Using throughputs and response¬ 
time distributions as reward rates, we have 
been able to handle systems with multiple 
resources as well as soft- and hard-dead¬ 
line constraints. Transient analysis of 
Markov reward models is the basis of our 
analysis. Stochastic reward nets are used to 
generate and solve these models. 

Our technique can be extended to cases 
with multiple types of tasks and mixed 
hard and soft deadlines. Processing power 
and cost-based trade-off studies, along with 
other such design optimizations, can be 
carried out much as Shin and Krishna dem¬ 
onstrated. Imperfect coverage, failure de¬ 
pendencies, and complex fault-handling 
behavior can also be taken into account.® 
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Experiments with a Program 
Timing Tool Based on 
Source-Level Timing Schema 


Chang Yun Park and Alan C. Shaw 
University of Washington 


O ur goal is to develop tools and 
techniques for predicting the de¬ 
terministic timing behavior of 
programs coded in contemporary higher 
level languages. Achieving this goal would 
permit performance guarantees before 
programs are run and, more generally, would 
allow a priori analysis of software timing 
properties. This is important for many real 
time systems, where failure to meet timing 
deadlines can result in unacceptable hu¬ 
man and property losses and where sto¬ 
chastic data is not sufficient. (Stochastic 
measures deal with statistical behaviors, 
such as average program performance. We 
are concerned with deterministic timing, 
by which we mean either an exact time or 
a tightly bounded time.) 

We believe that software timing proper¬ 
ties should be specified and verified at the 
source-program level rather than at the 
assembly or machine levels, since the former 
is the notation where programs are written, 
analyzed, debugged, and maintained. The 
arguments for treating time at the source 
level are similar to those made for pro¬ 
gramming in a higher level language rather 
than an assembly language. 


An earlier version of this article appeared in Proc. 11th 
IEEE Real-Time Systems Symposium, Dec. 1990, 
pp. 72-81. 
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This timing tool, 
developed for a subset 
of C, predicts the 
deterministic execution 
times of programs. 


Preliminary and 
related work 

A reasoning methodology for determin¬ 
istic timing was introduced by Shaw. 1 This 
method is based both on timing schema for 
source-program constructs, which are 
essentially formulae for computing the 
lower and upper bounds for the execution 
times of these constructs, and on an asser- 
tional program logic extended with a real¬ 
time clock. The timing schema idea can be 
used in principle to predict deterministic 
execution times of programs in best- and 
worst-case bounds; however, it was evi¬ 
dent that much experimental work was 
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necessary to validate and refine the concept. 

Surprisingly, little research has been 
published on deterministic timing predic¬ 
tion. A standard method in practice is to 
actually run a program on representative 
test data and measure the execution times. 
While this approach is clearly useful, it has 
some of the same flaws as debugging: The 
test data may not cover the domain of 
interest, and measurements may not be 
feasible (or realistic) without setting up an 
actual production environment. 

Another common and useful technique 
is to simulate the target system using some 
specification or modeling language. 2 The 
problem here is that the results may not 
accurately reflect the target, since the sim¬ 
ulation model is only an approximation of 
the real system. 

The only efforts we know of that directly 
relate to ours are the time tool development 
of Mok and his students, 3 the Maxt approach 
(maximum execution time) to computing 
the maximum execution time of a program, 4 
and Stoyenko’s schedulability analyzer of 
real-time Euclid. 5 

Mok’s time tool graphically analyzes an 
assembly language stream to produce a worst- 
case path and computes execution times by 
simulating the machine. The tool was also 
expanded to analyze a higher level language 
program directly through annotations that 
are carried down into the assembly language 
level. However, it still relies on target hard- 
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ware simulation and extensive analysis of 
assembly language streams. 

Maxt also involves the analysis of a 
source program through time formula for 
high-level language statements; however, 
control costs are not handled explicitly. It 
introduced a few new language constructs, 
such as “scope” and “marker,” to help the 
analysis of larger statement blocks. 

In the schedulability analyzer, a pro¬ 
gram is decomposed into a tree of seg¬ 
ments. Then the time of each segment is 
computed, and the worst-case program 
execution time is determined from the 
segment tree. The analyzer also works in 
some processor-sharing and distributed 
environments with interprocess communi¬ 
cation and resource sharing. Blocking times 
of processes are predicted by simulating all 
possible paths and resource contentions. 

Current approach 

All of the above studies attempt to bound 
the worst-case execution time. Our work 
differs in several ways: We employ analyt¬ 
ic methods at the source-language level 
using formal timing schema that include 
control costs, handle interferences such as 
interrupts, and produce guaranteed best- 
and worst-case bounds. (Often, doing 
something too quickly is as unacceptable 
as doing it too slowly; hence, best-case 
performance is also a useful measure.) 

Our timing tool computes the determin¬ 
istic execution times for programs that are 
written in a subset of C and run on a bare 
machine. We wrote two versions of the tool 
using two granularity extremes for the 
atomic elements of the timing schema. 

We found several interesting results from 
our first experiments in building and using 
this kind of tool. First, for the relatively 
small programs tested, predicted times were 
close to actual measured times, indicating 
that deterministic predictions are indeed 
potentially practical. We also demonstrat¬ 
ed that in a practical setting—that is, using 
a popular language, compiler, and comput¬ 
er — the timing schema approach leads to 
a natural implementation partition into an 
abstract, system-independent portion and 
a lower level system-dependent part. The 
independent part can be viewed as defining 
the timing semantics of the programming 
language. The system-dependent part in 
our experiments illustrates some of the 
complexities of predicting code generation 
in a modern compiler. Third, the work 
points out some of the problems and fea¬ 
tures of many modern machine architec¬ 


tures that make deterministic predictable 
performance difficult. 

Overview 

Timing tool. Our timing tool predicts 
deterministic bounds of execution times 
for elementary expressions, control struc¬ 
tures, statements, and procedures. Given a 
program P and bounds for each loop, the 
tool computes estimates of the best- and 
worst-case execution times of P. 

The factors that affect a program’s exe¬ 
cution time are program logic, data values, 
and implementations by a compiler, run¬ 
time system, operating system, and ma¬ 
chine. Some information on program logic 
and data values must be provided by users 
because they are unpredictable in general. 
In the tool, we require the input of loop 
bounds only, specified as a minimum and 
maximum number of iterations. (There is 
an implicit assumption that the user gives 
correct input. Loop bounds could be the 
result of a formal proof or an informal 
specification.) The details of the compiler 
are analyzed to predict the possible code 
generated for each basic program element. 
The tool predicts the execution times of the 
possible code using the characteristics of 
the target machine. The effects of some 
nondeterministic features of the machine 
are included by translating them into deter¬ 
minate bounds. We also handle the inter¬ 
ference due to unavoidable clock inter¬ 
rupts. Experiments were done on a bare 
machine without an operating system. 

Timing schema approach. Shaw’s 
method of predicting the execution time of 
a high-level language statement 1 implies the 
following steps: 

(1) Decompose a statement into its prim¬ 
itive or basic components, as defined by the 
timing schema for the statement. These ba¬ 
sic components are called atomic blocks. The 
schema is language dependent, but system 
(compiler/machine) independent. 

(2) Predict the implementation (for ex¬ 
ample, the object code generated by the 
compiler) of each atomic block. We call this 
step code prediction. 

(3) Determine the execution times of the 
atomic blocks from the times of the ma¬ 
chine instructions produced by the imple¬ 
mentation. 

(4) Compute the execution time of the 
statement, using the times of the atomic 
blocks and timing schema for the statement. 


The time T of a statement or a block 5 is 
represented by a pair of best/worst-case 
bounds. That is, T(S) = [ t min (5), f max (5) ], 
where f min (5) and t max (5) are the best- and 
worst-case execution times of 5, respec¬ 
tively. (We will use uppercase T for a pair 
of time bounds and lowercase t for a scalar 
time.) 

For example, the execution time of 
statement S\:a = b + c\ could be computed 
in the following way (corresponding to the 
previous steps): 

(1) A timing schema corresponding to 
51 could be 

T(51) = T(b) + T(+) + T(c) + T(a) + T(=) 

The statement is decomposed into five 
atomic blocks, corresponding to b, +, c, a, 
and =. Here, addition over intervals is de¬ 
fined as follows: [ w, x ] + [ y, z ] = [ w + y, 
x + z] 

(2) Object code for each atomic block 
could be predicted as follows: 

b : mov M,R /* mov b,dO */ 

+ : add M,R /* add c,dO */ 

c : none 

= : mov R,M /* mov dO, a */ 

where M and R are generic memory loca¬ 
tions and registers, respectively. 

(3, 4) According to the timing schema, 
the execution time of 51 becomes the sum 
of the times of three predicted instructions. 

The execution times for control state¬ 
ments can be computed similarly. For in¬ 
stance, the timing schema for 5: if (exp) then 
51 else 52 is 

T(S) = [ min(tl low , f2 low ), max(tl up , f2 up ) ] 

where [fl low , fl up ] = T(exp) + T(51) + 
T(then), [f2 low , f2 up ] = T(exp) + T(S2) + 
T(else) , and T(then) and 7Telse) denote 
control flow times (times to transfer to and 
from 51 and 52). 

Target language and system. We tested 
whether our timing schema approach could 
produce useful best- and worst-case exe¬ 
cution time bounds for modern high-level 
languages and their underlying systems. 
We chose a subset of C, the Gnu C compiler 
(nonoptimizing option), and the MC68010- 
based Sun 2/100U as the target language, 
compiler, and machine, respectively. 

The subset of C is small enough to be 
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tractable and large enough to write some 
interesting programs. In the second ver¬ 
sion, it includes expressions with simple 
arithmetic and relational operators; as¬ 
signment statements; if and while state¬ 
ments; and procedure calls, where a simple 
operator means an operator whose imple¬ 
mentation is not a library call. Any simple 
data type including array, pointer, and 
structure is allowed, but float and long 
(which require library calls) are not. The 
criteria for deciding the subset was its ease 
for constructing a simple prototype of the 
tool. The excluded features such as logical 
operators and complex operators could be 
added, but it would require some care; for 
example, library calls and system calls 
would be treated like special kinds of pro¬ 
cedure calls with predetermined execution 
time bounds (assuming these bounds are 
available or computable). 

The Gnu C-1.34 compiler from Free 
Software Foundation was selected mainly 
because its source programs are available 
for public scrutiny and modification. These 
programs clearly show how each high- 
level construct is compiled. Moreover, we 
can directly use the parser to analyze a 
program and produce atomic blocks for 
each timing schema. 

The CPU has a 10-megahertz clock and 
a 2-megabyte main memory (with no cache). 
There is also an AM9513 timer chip, which 
provides five user-programmable timers. 
Although the MC68010 has instruction 
prefetch and instruction execution overlap 
features, it executes most instructions de¬ 
terministically. Except for instructions with 
variable execution time and the occurrence 
of exceptions, each instruction nominally 
executes exactly according to its predefined 


Timing schema and 
code prediction 

A basic decision in defining timing sche¬ 
ma and predicting code is the granularity of 
an atomic block. We investigated small 
atomic block (SAB) and large atomic block 
(LAB) granularities. The SAB system per¬ 
mitted an extreme test through all elements 
of the language, while LAB lent itself to 
tighter timing predictions. 

Small atomic block. In the SAB ap¬ 
proach, atomic blocks correspond to the 
terminal symbols of the source language. 
Since each atomic block has some basic 
semantic meaning, the timing schema can 
be defined in a straightforward way, as in 


the example in ‘Timing schema approach.” 
Conceptually, code prediction can be easy 
if code generation follows the parsing struc¬ 
ture. For many modern compilers, this as¬ 
sumption is true for compiling control con¬ 
structs but may not be true for expressions. 

Many compilers generate efficient code 
through default optimizations, such as 
constant folding and register allocation. 
The generated code is tuned to the target 
machine. As a result, the compilers use the 
information of related atomic blocks to 
generate the code for one atomic block and 
sometimes consolidate several atomic 
blocks into one. (Some eminent compiler 
writers emphasize a simpler, less optimized 
approach for clarity and maintainability. 6 ) 

For example, in the compiler we used, 
the sequence of statements a = b + c;d = d 
+ a can be compiled as follows; 

a = b + c; ==> mov @b, dO 
add @c, dO 
mov dO, @a 

d = d + a; ==> add dO, @d 

where @a means the memory address of 
variable a, and dO means data register 0. 

The first statement is compiled to three 
instructions without optimizations. How¬ 
ever, the second statement (which has the 
same structure as the first) is compiled to 
just one assembly instruction, because a is 
already in the register and d is both the 
destination and one of the operands. 

These kinds of optimizations cause two 
problems in applying the timing schema 
approach in its pure form. First, it becomes 
hard to precisely predict the actual com¬ 
piled code of an atomic block because the 
code can vary widely, depending on the 
context. Second, sometimes two or more 
atomic blocks are merged into one machine 
instruction, also depending on the context. 
In the above example, two atomic blocks, 
add (+) and assignment (=), are imple¬ 
mented by one instruction, add d0,@d. In 
this case, it is not clear what corresponds to 
the implementation of add and what corre¬ 
sponds to assignment. These two related 
problems complicate code prediction for 
an atomic block. 

One solution to the above problems, 
which yields tighter code predictions, in¬ 
volves parameterized timing schema. 
Contextual information is generated in 
statement analysis and passed to code pre¬ 
diction through parameters in the timing 
schema. As an example, a parameterized 
timing schema for an assignment state¬ 
ments: <var>=<exp>; may be T(S) = T(var, 
var_type) + T(=, var_type, exp_type) + 


T(exp, exp_type), where the parameters 
var_type and expjype are determined in 
statement analysis. 

Large atomic block. This approach 
defines atomic blocks as large as possible. 
When a block such as an assignment state¬ 
ment generates straight-line code (no 
branches), further decomposition into 
smaller elements is not necessary because 
the time of the block is simply the sum of 
the times of each instruction in the code. 
The LAB idea considers such a straight- 
line block as an atomic block; for example, 
an assignment statement a = b + c; is con¬ 
sidered one atomic block. Several assign¬ 
ment statements could be combined into 
one atomic block, but a control statement 
such as an If should be decomposed into 
multiple blocks. 

LAB can eliminate the problems caused 
by some compiler optimizations. By 
matching atomic blocks to code generation 
units of a compiler, we can predict the code 
of an atomic block in the same way a 
compiler generates and optimizes its code. 
If the compiled code of a program is avail¬ 
able, code can be predicted simply by 
lookup; code generation and optimization 
inside a block are transparent to code pre¬ 
diction. 

A block can be atomic as long as it 
consists of straight-line code. However, 
there are some subtleties that require fur¬ 
ther study. For example, an apparently 
straight-line block may be implemented 
with branching code: A simple multiplica¬ 
tion may be implemented by a sequence of 
shifts, adds, and branches. 

Timing schema and code prediction for 
the C subset. We have applied two ap¬ 
proaches to the C subset, SAB in the first 
version and LAB in the second. A partially 
parameterized timing schema with SABs 
was tested in the first version. Park 7 describes 
the details of the timing schema and code 
prediction in the SAB version. Below, we 
explain the simpler LAB method. 

First, an atomic block for our C subset 
and tool is defined as follows: 

(1) Every expression statement is an 
atomic block. 

(2) Every control construct has one or 
more atomic blocks corresponding to pos¬ 
sible transfer of control. 

This definition provides a straightfor¬ 
ward correspondence between the atomic 
blocks of the timing schema and the code 
generation rules of the compiler. In Figure 
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1, the schema for a While statement is the 
sum of its constituent expression, state¬ 
ment, and control, essentially as suggested 
by Shaw. 1 For an expression statement S: 
exp;, the schema is simply T(S ) = r(exp code ), 
where exp code is the predicted sequence of 
codes for exp. 

Code prediction for an atomic block is 
achieved by looking up the compiled as¬ 
sembly code and extracting the corre¬ 
sponding part. An extended compiler gen¬ 
erates markers between the codes of atomic 
blocks; code prediction is then the result of 
an easy matching operation. The remain¬ 
ing constructs of the C subset are handled 
in a similar manner, with a schema for the 
construct and system-dependent code pre¬ 
diction. 

Machine analysis 

Instructions with variable execution 
times. On the MC68010, some instruc¬ 
tions have variable execution times that 
depend on operand values and machine 
status. These include shift and multiple 
data move instructions, whose execution 
times are variable but predictable from 
their operand value; multiply,* whose time 
is unpredictable; and conditional jump, 
where the time depends on whether the 
branch is taken or not. In the tool, these 
execution times are described by time 
bounds (such as shift), or only a worst-case 
time (such as multiply), or by treating the 
best and the worst case as different instruc¬ 
tions (such as conditional jump). 

System interferences. For a program to 
execute without interruption, we eliminate 
the sources of some interferences and pre¬ 
vent others by disabling the interfering 
process. However, some interferences 
cannot be eliminated or should not be pre¬ 
vented. In this subsection, we describe two 
such interferences: a clock interrupt and 
memory refresh. 

Time or clock services are important in 
computer systems, especially in hard real¬ 
time systems where timing behavior must 


*The execution times of multiply is decided by an 
internal micro-instruction algorithm that is unpredict¬ 
able at the machine-instruction level. The MC68010 
processor manual gives only the upper time bound (that 
is, the worst case); the lower bound is undefined. 
Experiments show that the execution times for very 
simple cases (possibly the best cases) are only slightly 
smaller than the worst time. Thus, we assume that the 
best time is the same as the worst time. 


be monitored. We also need a time service 
in our experiments to measure real execu¬ 
tion times for comparison with predicted 
times. Time services are often provided 
through a clock interrupt that comes from 
a hardware or a timer chip, as in our target 
system. (We could directly read/write times 
in the Am9513 timer chip and avoid using 
an interrupt. However, the times that can 
be represented in the chip are too short to 
measure a long execution because of the 
limited size of the internal registers.) We 
use our home-built clock utility whose in¬ 
terrupt handling time, a source of interfer¬ 
ence, is 70 microseconds. 

Another interference comes from ma¬ 
chine hardware. The main memory of our 
target system, composed of dynamic RAMs, 
must be restored periodically to maintain 
its content. The memory refresh process 
has higher priority in accessing the memo¬ 
ry than the CPU does. Thus, it impedes the 
execution of a normal program running on 
the CPU. 

Because we could not find any detailed 
quantitative data on the effects of memory 
refresh on program execution times, we 
made our own hardware measurements with 


an oscilloscope. The results were surprising 
to us in at least two ways. First, memory 
refresh is the main source of nondetermin¬ 
ism in the target machine. Second, the amount 
of nondeterminism and the effects of mem¬ 
ory refresh are much larger than expected 
(based on data published by the manufac¬ 
turer for a similar Sun 68000 board), mainly 
due to bus arbitration costs. Our measure¬ 
ments showed that memory refresh is ac¬ 
complished by performing 128 memory 
cycles (each taking four clock cycles) in 
sequence, one per row address, at a rate of 
one cycle every 13 microseconds; an addi¬ 
tional one or two clock cycles are required 
for the bus arbitration before and after each 
refresh cycle. From this, we computed that 
a worst-case (but unlikely) processor slow¬ 
down was 6.7 percent and that a minimum 
slowdown was 0 percent (also very unlikely); 
we observed that a frequent slowdown ap¬ 
peared to be 5 percent with considerable 
variation above and below. 

Effects of system interferences. System 
interferences complicate timing analysis. 
However, their effects can be estimated if 
they have determinate characteristics, such 


Statement; 

S : while (exp) stmt; 

Timing schema: 

T(S) = (N+l) ■ T(exp) + N • T(stmt) + T(while,N) 
where N is a pair of loop bounds (i.e., N = [n min , n ma J). 

Gnu C’s code generation rules: 


start_loop LI: 

exp exp 

S ==> exit_if_false ==> JRF L2 

stmt stmt 

end_loop JR A LI 

L2: 


where JRF means “jump_relative if false,” 
and JRA means “jumpjrelative always.” 

Code prediction: 

T(exp) : T(exp code ) 

T(stmt) : T( stmt code ) 

T(while,N) : N ■ T(JRF,fail) + T(JRF,succ) + N • T(JRA) 
where exp code and stmt code are predicted codes for 

exp and stmt, and JRF,fail is a jump instruction whose branch is not taken. 


Figure 1. Timing schema and code prediction for While statement. 
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as bounded frequency and duration. In this 
section, we introduce two complementary 
techniques to handle the effects of some 
system interferences. One approach in¬ 
volves adjusting the measured data; the 
other adjusts the time prediction. 

Measured data can be adjusted simply 
by removing interference times from mea¬ 
sured times. We consider the effect of a 
clock interrupt as an example. 

Suppose that clock interrupt period 
(Pciock) and interrupt handling time (f clock ) 
are given. Let a measured execution time 
of program P be t ™, which is a multiple of 
Pciock- Then, clock interrupts occur 
tp / p clock times during the execution of P, 


and its total interference time is 
(r™ / p dxk ) ■ (dock- Thus, adjusted time t' P , 
the pure execution time of program P, 



P clock 


This is the technique used in our timing tool. 

The second method, adjusting the time 
prediction, includes interference effects 
directly in program execution times. Shaw 1 
presented such a timing analysis for pro¬ 
cessor sharing between a user process and 
one or more interrupt handlers. Not sur¬ 


Preprocessor 



Parser: analyzes the input C program, statement by statement. 

Procedure times: manages the table of procedure names and their execution 
times. 

Loop bounds: interacts with a user to obtain loop bounds. 

Time schema: analyzes a statement into atomic blocks and computes the 
execution time of the statement using the times of the atomic blocks computed 
in code prediction. The timing schema are applied here. 

Code prediction: predicts the exact code for a given atomic block by looking up 
the assembly code prepared by the preprocessor and computes the time of the 
block using instruction execution times provided by the architecture analyzer. 


Figure 2. Organization of language analyzer. 


prisingly, it gives the same formula as 
shown above. In this approach, the granu¬ 
larity of adjustment is significant. At one 
extreme, we can apply the adjustment 
whenever the time of an atomic block is 
predicted; at the other extreme, we can 
adjust the time of a whole program after it 
has been predicted. The result in the first 
case potentially produces looser bounds 
because of the possibility of dealing with 
more fractional interrupts. 


Timing tool design 

The timing tool consists of the prepro¬ 
cessor, the language analyzer, and the ar¬ 
chitecture analyzer. The preprocessor has 
two major functions. First, it interprets 
user commands and prepares the working 
environment for the tool, including the 
compiled assembly code with atomic block 
markers of a source program. Second, it 
converts the internal time scale (clock cy¬ 
cles) into a real time scale (microseconds). 
The language analyzer, the heart of our 
timing tool, is decomposed into the five 
functional blocks shown in Figure 2. The 
time schema block is system independent 
but language dependent, while code pre¬ 
diction is a function of the compiler and 
architecture. The architecture analyzer 
maintains instruction execution times for 
access by the language analyzer. 

We built the parser of our tool by mod¬ 
ifying the parser of the Gnu C compiler. 
Adding some lines to several compiler 
source files is sufficient to extend the com¬ 
piler with atomic block markers. Figure 3 
shows a binary search example using the 
LAB version of our timing tool. Time 
bounds as a pair of clock cycles are output 
at the end of each statement. In the middle 
of the figure, “1 4” is the user’s loop bounds 
input, which can be derived from the 
knowledge that the number of data items is 
less than 15. The tool gives two predic¬ 
tions, one for the whole procedure time 
including control transfer and register sav¬ 
ings and the other for the procedure body 
only. The latter is used to validate a predic¬ 
tion with the measured time. 


Experiments and 
validation 


Measurement techniques. Our basic 
measurement technique is the control/test 
loop method, similar to that described by 
Clapp. 8 A control loop contains time mea- 
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surements and loop control for iterations, 
and a test loop is a modified control loop 
that includes the program to be measured. 
The execution time of a program is com¬ 


puted by taking the difference between the 
measured times of the control loop and the 
test loop. With a 5-millisecond tick period 
and 1,500,000 iterations, the maximum 


struct { 


int key; 
int value; 

) data[15]; 


binary_search(x) 


int fvalue, mid, up, low ; 


low = 0; 

[ 16,16] 

up = 14; 

[ 20,20 ] 

fvalue = -1 /* all data are positive */ ; 

[20,20] 

while (low <= up) 


*** WHILE statement *** 
Input LOOP-BOUNDS 

[ low up ]: 1 4 

mid = (low + up) » 1; 

[52,52] 

if ( data[mid].key == x ) { /* found */ 


up = low - 1; 

[ 40,40 ] 

fvalue = data[mid], value; 

[ 72,72 ] 

j 

[ 112, 112] 

else /* not found */ 


if ( data[mid].key > x ) up = mid - 1; 

[ 40,40 ] 

else low = mid + 1; 

[ 40,40 ] 

[ 128, 134] 

[ 206,222 ] 

) 

[ 258,274 ] 

[ 352 , 1340 ] 

return fvalue; 

[ 26,26 ] 

j 

[ 434,1422 ] 

*** Target procedure( binary_sea ) 

Cycles = [ 478 , 1466 ] 

Times = [ 48.62,149.13 ] (microseconds) 


*** Target procedure( binary_sea ) body time 


Cycles = [ 434,1422 ] 

Times = [ 44.15 , 144.65 ] (microseconds) 



Figure 3. An example using the timing tool. 


measurement error is 0.01 microseconds. 7 
This error is so small that it can be ignored, 
because the shortest instruction execution 
time is 0.4 microseconds. (To increase our 
confidence in this kind of data, we con¬ 
firmed the clock frequencies of the ma¬ 
chine and the timer chip using an oscillo¬ 
scope.) 

Validation approach. To validate the 
tool’s predictions, we experimented with 
different sample programs and compared 
their measured times to the time bounds 
predicted by the timing tool. Test data for 
the best/worst cases of a sample program 
were generated by tracing the program’s 
shortest and longest execution paths. Ide¬ 
ally, we can say that the tool gives a safe 
prediction if every measured time is within 
the predicted time bounds. However, sys¬ 
tem interferences (see “Machine analy¬ 
sis”) will increase measured times. To han¬ 
dle this problem, we introduce the notion 
of a pure execution time , the execution time 
if there were no interferences. (Pure execu¬ 
tion time of a program is computed by 
hand, tracing paths and counting cycles 
from the assembly program generated by 
the compiler.) Safe prediction is then de¬ 
fined as follows: Pure execution times must 
be within the predicted time bounds. 

It is often the case that pure execution 
times are not available. Then, measured 
times will determine safety. We adjusted 
the measured times by removing the effect 
of a clock interrupt. (All “measured time” 
data in the table refer to this adjusted mea¬ 
sured time.) Even after this adjustment, we 
still get a maximum 7 percent longer mea¬ 
sured time (see Table 1) than the pure 
execution time, which we can attribute to 
dynamic RAM refresh interference (see 
“System interferences”). Thus, we use the 
following simple sufficient condition for 
safe prediction: The measured time of the 
worst case is smaller than the upper bound 
of the prediction, and that of the best case 
decreased by 7 percent is greater than the 
lower bound. A necessary condition is that 
the worst measured time decreased by 7 
percent may not be greater than the upper 
bound, and the best measured time may not 
be smaller than the lower bound. 

However, when a measured time is very 
close to the prediction, the above simple 
conditions do not always determine safety. 
For example, the sufficient condition may 
fail even though a prediction is safe. If a 
prediction is extended to include interfer¬ 
ences as well as a pure execution time, a 
prediction corresponds directly to a mea¬ 
sured time; we can then validate the safety 
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Table 1. Times of language constructs. 


Language 

Predicted 

Predicted 

Measured 

Pure 

construct* 

time bounds 

time bounds 

time 

execution 


( SAB) 

(LAB) 

(psec ) 

time 

Expression: 





a + b; 

[ 1.42,3.46] 

[ 3.46,3.46 ] 

3.66 

3.46 

a * b; 

[ 5.29,7.32 ] 

[6.31 ,6.31 ] 

6.43 

6.31 

a > b; 

[ 2.44,4.07 ] 

[ 3.86,3.86 ] 

3.97 

3.86 

a[b]; 

Assignment: 

[3.86,5.09 ] 

[ 4.27,4.27 ] 

4.42 

4.27 

a = b; 

[ 1.22,2.03 ] 

[ 2.03,2.03 ] 

2.15 

2.03 

a = b + c; 

[ 1.63,4.07 ] 

[ 3.66,3.66 ] 

3.91 

3.66 

If: 





simplejf: 

[ 3.46,4.48 ] 

[ 3.86,4.48 ] 

[3.98,4.71 ] 

[ 3.86,4.48 ] 

While: 





simple_while: 
Procedure call: 

[ 1.83,6.71 ] 

[2.24,6.31 ] 

[ 2.34,6.62 ] 

[2.24,6.31 ] 

null_proc_call: 

[ 6.72,26.44 ] 

[6.72,6.72 ] 

6.97 

6.72 


simplejf: 

simple_while: 

null_proc_call 




if(a)b = 1; **best time when a is zero 
else c = 1; worst time when a is nonzero 

while(a) a = 0; **best time when a is zero 

worst time when a is nonzero 

prcd(); 

where prcd() { ; } 


of a prediction with respect to a measured 
time. We say that the measurements and 
predictions are consistent if the predicted 
bounds adjusted for all possible interfer¬ 
ences cover the measurements. On the one 
hand, prediction and validation, including 
such unavoidable interferences as inter¬ 
rupts and memory refresh, may be more 
practical than using pure execution times 
only, because these adjusted times are 
eventually part of any real execution. On 
the other hand, they are less rigorous in 
testing the correctness of a prediction be¬ 
cause some errors in the prediction may be 
covered by the adjustment. 

Experiments were conducted in three 
stages. First, we predicted, measured, and 
validated each language construct of our 
subset C. Next, we tested simple proce¬ 
dures whose execution paths are complete¬ 
ly known. Finally, more complex proce¬ 
dures were tested and analyzed. 

Experiments. Table 1 presents the tim¬ 
ing data for most of the basic C constructs 
used. First, we can say that time prediction 
with SAB for each language construct is 


safe because every pure execution time 
(and most measured times) is included in 
the corresponding predicted time bounds. 
(Measured execution times for code gener¬ 
ated by sequences of a=b+c; were checked 
electronically by an oscilloscope to give us 
more confidence that our measured results 
were correct.) 

In most cases, the tool gives very tight 
upper bounds but looser lower bounds, 
except in a procedure call, where the num¬ 
ber of saved registers can vary widely. The 
LAB predictions are identical to the pure 
execution times for every construct, as 
expected, because we defined the atomic 
blocks to be compatible with the target 
compiler. 

The results of experiments on five sim¬ 
ple procedures are shown in Table 2, where 
the adjusted bounds are added. Since arr- 
sum has only one execution path, its data 
illustrates how precisely the tool predicts 
the execution time of a specific path. Other 
procedures have multiple execution paths 
based mainly on the number of loop itera¬ 
tions and input data. The tool predicts the 
best and worst of those variable data-de- 


pendent execution times. To validate the 
predictions, we generated the best- and 
worst-case data and measured the time of 
each. 

The tool gives very tight predictions for 
all the procedures—too tight to be validat¬ 
ed by our simple sufficient condition (see 
“Validation approach”). All predictions 
satisfy the necessary condition for safety. 
When interference due to memory refresh 
is taken into account, as in the second 
column (the same lower bound for the best 
case with no interference and about 7 per¬ 
cent higher upper bound for the worst case 
with maximum interference), the predic¬ 
tions and measurements are consistent. The 
only unusual result is that the lower bound 
of sqrt seems too close to the best execu¬ 
tion time. However, it could be explained 
by the observation that multiplication is 
dominant in sqrt; the worst-time data for 
the multiply instruction yields a higher 
prediction, and less interference from 
memory refresh during multiplication re¬ 
sults in a smaller measurement. Finally, it 
is worth noting that these tight bounds are 
possible because loop bounds are suffi¬ 
cient to describe the execution paths of the 
procedures. 

We tested an insertion sort program and 
a modified version of a multiprocessor 
scheduler algorithm as more complex ex¬ 
amples (see Table 3); the scheduler pro¬ 
gram, for example, consists of 160 lines of 
C code. The tool produces safe but loose 
bounds for both of them. The lower bound 
of the complete scheduler is six times less 
than the measured time, although the pre¬ 
diction for each phase (PI, P2, P3) is much 
tighter. 

Execution time is heavily dependent on 
the program execution path, and the logic 
of most programs severely limits the set of 
possible execution paths. For example, the 
scheduler program has an interesting rela¬ 
tion between the phases, PI and P2. The 
best case of P2 (that is, ready_process = 
false) occurs only when the worst case of 
PI (that is, no ready processes in the pro- 
cesslist) happens. This is the main reason 
for the looseness of the scheduler’s lower 
bound. 

Both the insertion sort and the scheduler 
have a nested loop where the maximum 
number of iterations in the inner loop is a 
function of the outer loop index value. In 
such a nested loop, the time of the inner 
loop is changed with every outer loop iter¬ 
ation. The pure timing schema approach 
cannot handle such interrelations among 
program statements. We also assume here 
that the execution time of a loop body is 
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Table 2. Times of simple procedures. 


constant. As a result, the tool produces 
loose bounds for these procedures. (Simi¬ 
lar results were obtained with SAB on both 
simple and complex procedures, but with 
looser bounds. 7 ) 

One lesson we learned from the complex 
program experiments is that the use of loop 
bounds as the only program execution in¬ 
formation may not be sufficient, because 
many impossible (infeasible) paths may be 
added. In recent experiments, we have test¬ 
ed more complicated user input where a 
user can pick a path (then or else) in an 
alternative (if) statement (even inside a 
simple loop). This user input can specify 
one execution path, and the tool then can 
predict a very tight time for that path, for 
example, as in the procedure arrsum. If the 
best and worst execution paths of a program 
can be specified by a user’s input, the tool 
can predict the time bounds of the best- and 
worst-case execution, respectively. Then, 
the guaranteed time bounds of the program 
are the result of merging two bounds, the 
lower bound of the best path and the upper 
bound of the worst. For the scheduler in 
Table 3, we could achieve the very tight 
prediction [ 256.55, 3356.34 ]. We are go¬ 
ing to develop this idea further. Some related 
issues will be mentioned in the next section. 

The results of our experiments can be 
summarized as follows. All the predicted 
times are consistent, and most are safe. 
Some predictions are fairly tight, while 
others are a little loose. There are clear 
technical reasons that explain the differ¬ 
ences between measured and predicted 
times, and we see technical solutions that 
should minimize these differences within 
the timing schema framework. 


Issues and future work 

Table 3. Times of complex procedures. 


Predicted 
time bounds 
(LAB) 


Time bounds 
adjusted for 
memory refresh 


Measured 


arrsum 
bi _search 
maxi 
sqrt 
fib 


[ 155.64 , 155.64 ] 
[44.15 , 144.65 ] 

[ 7.73,60.22 ] 

[ 10.78, 113.32] 
[7.93,121.46] 


[ 155.64 , 166.17 ] 
[44.15 , 154.76] 

[ 7.73,64.27 ] 

[ 10.78 , 121.42] 
[7.93 , 129.56] 


160.39 

[ 47.0,147.57 ] 

[ 8.56,63.81 ] 

[ 11.00, 115.79] 
[ 8.37 , 127.95 ] 


arrsum() : 
i = 0; 


return sum ; 
maxl(a,b) : 


if ( x < 1 ) x = 1; 
while (x<b)x = x 


while ( a * a < x ) 
a = a + 1; 

fib(n) : 

Fnew = 1; Fold = 0; 
i = 2; 

while( i <= n ) { 
temp = Fnew; 

Fnew = Fnew + Fold; 
Fold = temp; 


* For 10 array elements, 
best : # loop =10 

worst : # loop = 10 


* For a,b <= 10, 

best : a = 10, b = 1 
worst : a = 0, b= 10 


==> # loop = 0 
==> # loop = 9 


* For 1 <= x <= 100 

best : x = 0 ==> # loop = 0 

worst : x = 100 ==> # loop = 9 


* For 1 <= n <= 10 
best ; n = 1 
worst : n = 10 


==> # loop = 0 
==> # loop = 9 


} 


Our timing schema approach produced a 
convenient division between the more ab¬ 
stract programming language timing units 
and the lower level compiler/machine-ori¬ 
ented units, with a parameterized interface 
to the latter. Further programming and paper 
experiments with other language/compiler/ 
machine combinations are needed to 
determine whether such a clean partition 
always exists, whether language timing se¬ 
mantics are independent of the lower levels, 
and whether parameterized schema and/or 
LABs are a tractable framework for orga¬ 
nizing the lower level code rules. 

One attractive refinement of the timing 
tool is using more detailed execution path 
information. The recent experiments dis¬ 
cussed in the previous section showed that 


Procedure 

Predicted 
time bounds 

Measured 

times 1 

Insertion sort 2 

[ 187.17,3450.10] 

[ 197.2,2071.1 ] 

Scheduler 3 

[ 51.88,4253.31 ] 

[ 280.68,3242.6 ] 

- search_processlist 

[ 25.84,838.21 ] 

[ 37.14,826.6 ] 

- allocate_idle 

[ 25.02 , 129.29 ] 

[ 52.26 , 127.2 ] 

- preempt 

[ 105.38,225.02 ] 

[ 113.72,230.7] 


Scheduler: 

repeat 


search_processlist /* PI */ 
if ready_process then allocate_idle /* P2 */ 
if ready_process and no_idle_processor then preempt /* P3 */ 
until no_ready_process or not_preemptable 


1 All data are obtained with 150,000 iterations. 

2 The number of data elements sorted is 10. 

3 The scheduler allocates five processors. 
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very tight bounds could be predicted with 
such interactions and that path data could 
be easily introduced into the existing tool 
without spoiling the timing schema frame¬ 
work. However, more fundamental studies 
are required. We need a better understand¬ 
ing of what kind of execution path infor¬ 
mation is valuable for prediction. It is then 
necessary to investigate verifiable ways in 
which the information should be gathered 
from specifications, program contexts, and 
users. Methods for merging this informa¬ 
tion into the timing schema framework 
should also be developed. 

Some refinements of the schema idea 
could yield tighter timing bounds on pro¬ 
grams, but these should not sacrifice the 
essential simplicity of the concept. In par¬ 
ticular, we are considering the combina¬ 
tion of assertional program logic with the 
schema so that context can be taken into 
account when deriving bounds for specific 
programs. Similar improvements may be 
obtained using symbolic execution tech¬ 
niques; an interesting combination of path 
tracing and symbolic computation, not in¬ 
volving time, is described for concurrent 
programs by Young. 9 

Instruction times in contemporary com¬ 
puters seem notoriously nondeterministic 
(unpredictable), not only because machines 
contain a myriad of complex performance¬ 
enhancing features, such as caches and 
pipelining, but also because they have a 
number of architectural elements that are 
hidden from the programmer, including vir¬ 
tual memory implementations, dynamic 
memory refresh, interrupts, and hardware 
monitors. Careful analysis of a relatively 
simple processor such as the MC68010 can 
account for many of the causes of nondeter¬ 
ministic timing and lead to satisfactory, if 
not perfect, predictions. More machines need 
to be studied in a similar way. It is possible 
that features such as caches can be handled 
by incorporating their effects at a large 
enough granularity or by hardware modifi¬ 
cations that allow data and instructions to be 
locked in. A long-term solution to this prob¬ 
lem could very well be RISC-like machines 
with instructions that have equally simple 
timing properties, at some possible sacri¬ 
fice in performance. 

Because of some of the above problems 
and measurement difficulties, it has prov¬ 
en surprisingly difficult to precisely vali¬ 
date our deterministic timing predictions. 
(It took much longer than we care to admit 
before we realized that it was necessary to 
also obtain more precise data on hardware, 
through oscilloscope measurement.) 

Clearly, a necessary condition for cor¬ 


rectness is that measured results be close to 
predicted ones. But how close is good 
enough? More work is required to get a 
better understanding of these issues. Cer¬ 
tain classes and structures for programs are 
more amenable to timing analysis than 
others, for example those without dynamic 
elements (dynamic data structures, pro¬ 
cesses, types, object instantiations, etc.). 
Also, it would be useful to characterize 
these classes precisely and understand their 
timing behaviors. Our present ideas are to 
analyze with dynamic elements using exe¬ 
cution paths. 

This first experimental test of our ideas 
has been confined to a subset of a sequen¬ 
tial programming language. The addition 
of more control and data structures would 
permit experiments with more realistic 
programs and with software systems. The 
timing schema approach can also be ap¬ 
plied to concurrent programs running on 
shared-memory multiprocessors and dis¬ 
tributed systems. We have been devising 
schema for parallel languages and defining 
the timing properties of standard process 
interactions, such as critical section lock¬ 
ing, message passing, and remote proce¬ 
dure calls. 10 Some initial experiments for 
parallel systems are reported by Kim. 11 A 
particular model for programming-in-the- 
large, based on unadorned processes and 
abstract data types, has recently been defined 
by us for real-time software 12 ; this model 
appears to offer a convenient framework 
for performing deterministic timing anal¬ 
ysis with our timing schema, and we plan 
to develop this combination further. 


O ur first experiments in building 
and using a software tool to predict 
the deterministic execution times 
of programs have been successful and 
promising. While many interesting and 
challenging problems must still be solved 
before such predictions are practical for 
realistic systems, our research has demon¬ 
strated that the timing schema approach can 
lead to a clean implementation and accurate 
predictions, and the remaining problems 
appear manageable with some effort. 

We are particularly pleased that we could 
construct a source-language-level tool and 
that many of the compiler and machine 
nondeterminisms became determinate af¬ 
ter careful study. We view this work not 
only as research in performance predic¬ 
tion, but also as the initial steps toward 
developing and validating a general meth¬ 
odology for reasoning about timing prop¬ 
erties of programs. ■ 
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I n a hard real-time system, every time- 
critical task must meet its timing con¬ 
straint, typically specified as its 
deadline. (A task is a granule of computa¬ 
tion treated by the scheduler as a unit of 
work to be allocated processor time, or 
scheduled.) If any time-critical task fails to 
complete and produce its result by its 
deadline, a timing fault occurs and the 
task’s result is of little or no use. Such 
factors as variations in the processing times 
of dynamic algorithms make meeting all 
deadlines at all times difficult. 

The imprecise computation technique' 3 
can minimize this difficulty. It prevents 
timing faults and achieves graceful degra¬ 
dation by giving the user an approximate 
result of acceptable quality whenever the 
system cannot produce the exact result in 
time. Image processing and tracking are 
examples of real-time applications where 
the user may accept timely approximate 
results: Frames of fuzzy images and rough 
estimates of location produced in time may 
be better than perfect images and accurate 
location data produced too late. 

In this article, we review workload mod¬ 
els that quantify the trade-off between re¬ 
sult quality and computation time. We also 
describe scheduling algorithms that ex¬ 
ploit this trade-off. 


— 


Imprecise computation 
techniques provide 
scheduling flexibility 
by trading off result 
quality to meet 
computation deadlines. 

We review imprecise 
computation scheduling 
problems: workload 
models and algorithms. 


Imprecise computation 
technique 

A basic strategy to minimize the bad 
effects of timing faults is to leave the less 
important tasks unfinished if necessary. 


The system schedules and executes to com¬ 
pletion all mandatory tasks before their 
deadlines, but may leave less important 
tasks unfinished. 

The imprecise computation technique 
uses this basic strategy but carries it one 
step further. In addition to dividing tasks 
into mandatory and optional, programmers 
structure every time-critical task so it can 
be logically decomposed into two subtasks: 
a mandatory subtask and an optional sub¬ 
task. The mandatory subtask is required 
for an acceptable result and must be com¬ 
puted to completion before the task dead¬ 
line. The optional subtask refines the result. 
It can be left unfinished and terminated at 
its deadline, if necessary, lessening the 
quality of the task result. 

The result produced by a task when it 
completes is the desired precise result, 
which has an error of zero. If the task is 
terminated before completion, the inter¬ 
mediate result produced at that point is 
usable as long as the mandatory subtask is 
complete. Such a result is said to be im¬ 
precise. A programming language in which 
imprecise computations can be easily im¬ 
plemented is Flex, 1 an object-oriented 
language that supports all C++ constructs 
along with timing-constraint and impreci¬ 
sion primitives. 
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Monotone time-critical computations 
provide maximum flexibility in scheduling. 
A task is monotone if the quality of its 
intermediate result does not decrease as it 
executes longer. Underlying computational 
algorithms enabling monotone tasks are 
available in many problem domains, in¬ 
cluding numerical computation, statistical 
estimation and prediction, heuristic search, 
sorting, and database query processing. 4 

To return an imprecise result of a 
monotone task, the intermediate results 
produced by the task are recorded at ap¬ 
propriate instances of its execution. Flex 
provides language primitives with which 
the programmer can specify the intermediate 
result variables and error indicators, as 
well as the time instants to record them. 
The latest recorded values of the interme¬ 
diate result variables and error indicators 
become available to the user if the task 
prematurely terminates. The user can ex¬ 
amine these error indicators and decide 
whether an imprecise result is acceptable. 
This method for returning imprecise results 
is called the milestone method. 

For some applications, making all com¬ 
putations monotone is not feasible. In this 
case, result quality can be traded off for 
processing time through sieve functions — 
computation steps that can be skipped to 
save time. In radar signal processing, for 
example, the step that computes a new 
estimate of the noise level in the received 
signal can be skipped; an old estimate can 
be used. 

In applications where neither the mile¬ 
stone method nor the sieve method is fea¬ 
sible, the multiple version method 5 almost 
always works. The system has two versions 
of each task: the primary version and the 
alternate version. The primary version 
produces a precise result but has a longer 
processing time. The alternate version has 
a shorter processing time but produces an 
imprecise result. During a transient over¬ 
load, the system executes a task’s alternate 
version instead of its primary version. 

Programmers can easily implement both 
the milestone and sieve methods in any 
existing language. Tools and environments 
have been developed to support the multiple- 
version method in real-time computing and 
data communication. 

The cost of the milestone technique is 
the overhead in recording intermediate 
results. The cost of the sieve technique is 
the higher scheduling overhead. Since there 
is no benefit in completing part of a sieve, 
while incurring the cost in processing that 
part, the execution of such an optional 
subtask must satisfy the 0/1 constraint: 


The system must either execute it to com¬ 
pletion before its deadline or not schedule 
it at all. Algorithms for scheduling tasks 
with the 0/1 constraints are more complex 
than the ones for monotone tasks. 2 

The cost of the multiple-version method 
is the overhead to store multiple versions, 
as well as the relatively high scheduling 
overhead. Scheduling tasks that have two 
versions is the same as scheduling tasks 
with the 0/1 constraint. For scheduling 
purposes, we can view the primary version 
of a task as consisting of a mandatory 
subtask and an optional subtask, and the 
alternate version as the mandatory subtask. 
The processing time of the mandatory 
subtask is the same as the processing time 
of the task’s alternate version. The pro¬ 
cessing time of the optional subtask in the 
primary version is equal to the difference 
between the processing times of the primary 
and alternate versions. Thus, scheduling 
the primary version corresponds to sched¬ 
uling the mandatory subtask and the entire 
optional subtask, while scheduling the al¬ 
ternate version corresponds to scheduling 
only the mandatory subtask. 

To ensure that imprecise computation 
works properly, we need to make sure that 
all the mandatory subtasks have bounded 
resource and processing time requirements 
and are allocated sufficient processor time 
to complete by their deadlines. The system 
can use leftover processor time to complete 
as many optional subtasks as possible. For 
guaranteed performance and predictable 
behavior, we can use a conservative 
scheduling discipline such as the rate- 
monotone algorithm 6 to schedule the 
mandatory subtasks. To schedule optional 
subtasks for optimal processor use, we can 
use more dynamic disciplines, such as the 
earliest-deadline-first algorithm, 6 which 
may have unpredictable behavior. Because 
a monotone task can be terminated any 
time after it has produced an acceptable 
result, the system can decide — on line or 
nearly on line—how much of each optional 
subtask to schedule. 

Basic workload model 

The problems in scheduling imprecise 
computations are at least as complex as the 
corresponding classical real-time-sched¬ 
uling problems. Almost all problems beyond 
scheduling unit-length, dependent tasks on 
two processors are NP-hard, and most 
known heuristic algorithms for multipro¬ 
cessor scheduling of dependent tasks have 
poor worst-case performance. 7 For this 


reason, a better approach to scheduling 
dependent tasks is first to assign the tasks 
statically to processors and then schedule 
the tasks on each processor using an opti¬ 
mal or near-optimal uniprocessor sched¬ 
uling algorithm. When the tasks are inde¬ 
pendent, optimal preemptive multiprocessor 
schedules can be obtained by transforming 
an optimal uniprocessor schedule using 
McNaughton’s rule. 8 

All the imprecise computation models 
are extensions and variations of the fol¬ 
lowing basic model. We have a set of 
preemptable tasks T = {7j, T 2 ,..., T„). Each 
task '/) is characterized by parameters, which 
are rational numbers: 

• Ready time r- at which T : becomes ready 
for execution 

• Deadline d- by which T ; must be com¬ 
pleted 

• Processing time x„ the time required to 
execute T, to completion in the tradi¬ 
tional sense on a single processor 

• Weight w„ a positive number that 
measures the relative importance of 
the task 

Logically, we decompose each task 7j 
into two subtasks: the mandatory subtask 
M, and the optional subtask O,. Hereafter, 
we refer to M i and O, simply as tasks rather 
than subtasks: M, and O, mean the manda¬ 
tory task and the optional task of T r We use 
T, to refer to the task as a whole. The 
processing times of M ; and O, are m, and o„ 
respectively. Here m, and o, are rational 
numbers, and m, + o, = t,. The ready times 
and deadlines of the tasks M, and O, are the 
same as those of T,. 

A schedule on a uniprocessor system is 
an assignment of the processor to the tasks 
in T in disjoint intervals of time. A task is 
scheduled in a time interval if the proces¬ 
sor is assigned to the task in the interval. A 
valid schedule assigns the processor to at 
most one task at any time, and every task is 
scheduled after its ready time. Moreover, 
the total length of the intervals in which the 
processor is assigned to T„ referred to as 
the total amount of processor time assigned 
to the task, is at least equal to m, and at most 
equal to T,. A task is completed in the tra¬ 
ditional sense at an instant t when the total 
amount of processor time assigned to it 
becomes equal to its processing time at t. 

A mandatory task M ; is completed when 
it is completed in the traditional sense. The 
optional task O, depends on the mandatory 
task M t and becomes ready for execution 
when Mi is completed. The system can 
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terminate O , at any time; no processor time 
is assigned to it after it is terminated. 

A task T ( is completed in a schedule 
whenever its mandatory task is completed. 
It is terminated when its optional task is 
terminated. Given a schedule S, we call the 
earliest time instant at which the processor 
is assigned to a task the start time of the task 
and the time instant at which the task is 
terminated its finishing time. 

The traditional workload model of hard 
real-time applications is a special case of 
this model in which all the tasks are man¬ 
datory, that is, o, = 0 for all i. Similarly, the 
traditional soft real-time workload model 
is also a special case in which all tasks are 
optional, that is, m ( = 0 for all i. 

Precedence constraints specify the de¬ 
pendences between the tasks in T. The 
constraints are given by a partial-order 
relation “<” defined over T. 7, < 7} if the 
execution of 7} cannot begin until the task 
T, is completed and terminated. 7} is a 
successor of 7„ and 7, is a predecessor of 
Tj, if 7, < Tj. For a schedule of T to be valid, 
it must satisfy the precedence constraints 
between all tasks. A set of tasks is inde¬ 
pendent if the partial-order relation is empty, 
and the tasks can be executed in any order. 
A valid schedule is feasible if every task is 
completed by its deadline. A set of tasks is 
schedulable if it has at least one feasible 
schedule. 

The given deadline of a task can be later 
than that of its successors. Rather than 
working with the given deadlines, we use 
modified deadlines consistent with the 
precedence constraints and computed as 
follows. The modified deadline d, of a task 
T, that has no successors is equal to its 
given deadline dj. Let Aj be the set of all 
successors of 7}. The modified deadline d s 
of Tj is 

minjd', min {d,} j 

Similarly, the given ready time of a task 
may be earlier than that of its predecessors. 
We modify the ready times of tasks as 
follows. The modified ready time r, of a task 
7, with no predecessors is equal to its given 
ready time rj. Let be the set of all pre¬ 
decessors of Tj. The modified ready time r ; 
of Tj is 

maxjr', max {^}| 

A feasible schedule on a uniprocessor 
system exists for a set of tasks T with the 
given ready times and deadlines if and only 
if a feasible schedule of T with the modi¬ 


fied ready times and deadlines exists. 7 
Working with the modified ready times 
and deadlines allows the precedence con¬ 
straints to be ignored temporarily. If an 
algorithm finds an invalid schedule in which 
Tj is assigned a time interval later than 
some intervals assigned to 7} but 7, < Tj, it 
can construct a valid schedule by exchang¬ 
ing the time intervals assigned to T i and 7 ; 
to satisfy their precedence constraint without 
violating their timing constraints. In our 
subsequent discussion, the terms ready times 
and deadlines mean modified ready times 
and deadlines. We call the time interval [r„ 
d,] the feasibility interval of the task 7,. 

When the amount of processor time o, 
assigned to O, in a schedule is equal to o„ the 
task 7, is precisely scheduled. The error 6, 
in the result produced by 7, (or simply the 
error of Tj) is zero. In a precise schedule, 
every task is precisely scheduled. Other¬ 
wise, if o, is less than o„ we say that a 
portion of O, with processing time o, - a, is 
discarded, and the error of 7, is equal to 

6, = E i (o t - a,) (1) 

where the error function Efaj) gives the error 
of the task 7, as a function of a,. We assume 
throughout this article that Efaj) is a 
monotone nonincreasing function of a,. 

Imprecise scheduling 
problems 

Depending on the application, we use 
different performance metrics as criteria 
for comparing different imprecise sched¬ 
ules. Consequently, there are many differ¬ 
ent imprecise scheduling problems. We 
describe some in this section. 

Minimization of total error. In prac¬ 
tice, the exact behavior of error functions 
E/x) is often not known. A reasonable 
choice is the simplest one: 

e, = o, - o, (2a) 


for all i. For a given schedule, the total 
error of the task set T is 



Again, w, > 0 are the weights of the tasks. 
Sometimes, we also refer to e as the total 
error of the schedule. The basic imprecise 
scheduling problem is, given a set T of n 
tasks, to find a schedule that is optimal in 
that it is feasible and has the minimum total 


error given by Equations 2a and 2b. An 
optimal scheduling algorithm always finds 
an optimal schedule whenever feasible 
schedules of T exist. In later sections, we 
consider this problem for dependent tasks 
on uniprocessor systems or independent 
tasks on multiprocessor systems. 

Minimization of the maximum or av¬ 
erage error. Two straightforward varia¬ 
tions of the minimization of total error 
performance metric are concerned with the 
average error and the maximum error. Giv¬ 
en a schedule of the task set T and the er¬ 
rors e, of the tasks, the maximum error of 
the task set is 

max [Wj 6| ] 

For some applications, we may want to 
find feasible schedules with the smallest 
maximum error, rather than the total error. 
There are polynomial-time, optimal algo¬ 
rithms for solving this scheduling prob¬ 
lem. (We are preparing a manuscript de¬ 
scribing them.) 

Minimization of the number of dis¬ 
carded optional tasks. In a schedule that 
satisfies the 0/1 constraint, a, is equal to o, 
or 0 for every task. The general problem of 
scheduling to meet the 0/1 constraint and 
timing constraints, as well as to minimize 
the total error, is NP-complete when the 
optional tasks have arbitrary processing 
times. Often — for example, when sched¬ 
uling tasks with multiple versions — we 
are concerned only with the number of 
discarded optional tasks. A reasonable 
strategy for scheduling to minimize the 
number of discarded optional tasks is the 
shortest-processing-time-first strategy, 
which tries to schedule the optional tasks 
with shorter processing times first. Given a 
set T of n tasks, N, and N 0 are the numbers 
of optional tasks discarded in a schedule 
produced using this strategy and discarded 
in an optimal schedule, respectively. Our 
conjecture is that N s < 2N„. 

When optional subtasks have identical 
processing times, tasks with 0/1 constraints 
and identical weights can be optimally 
scheduled in 0(n log n) time or 0(n 2 ) time, 
depending on whether the tasks have iden¬ 
tical or different ready times. Optimal al¬ 
gorithms for this case can be found else¬ 
where. 2 

Minimization of the number of tardy 
tasks. As long as the total error of the tasks 
is lower than a certain acceptable limit, its 
value is often not important. We may then 
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want to minimize the number of tasks that 
are tardy — that is, tasks that complete and 
terminate after their deadlines — for a 
given maximum, tolerable total error. Le¬ 
ung and Wong 9 presented a pseudopoly¬ 
nomial time algorithm and a fast heuristic 
algorithm for preemptive uniprocessor 
scheduling of tasks whose feasibility inter¬ 
vals include each other. In the worst case, 
the number of tardy tasks in a schedule 
found by the heuristic algorithm is approx¬ 
imately three times the number in an opti¬ 
mal schedule. 

Minimization of average response time. 

Given a schedule S and the, finishing time 
fiTj, S ) of every task, the mean flow time 
of the tasks according to the schedule is 
equal to 

F = £/(71,S)/ n 

The mean flow time of the tasks measures 
the average response time, the average 
amount of time a task waits until it com¬ 
pletes. The goal of scheduling is to mini¬ 
mize the mean flow time, subject to the 
constraint that the total error is less than an 
acceptable value. Unfortunately, all but 
the simplest special cases of this schedul¬ 
ing problem are NP-hard. 10 In a later sec¬ 
tion, we discuss the queuing-theoretical 
formulation, a more fruitful approach to 
this problem. 

Scheduling to minimize 
total error 

Two optimal algorithms for scheduling 
imprecise computations to meet deadlines 
and minimize total error use a modified 
version of the classical earliest-deadline- 
first algorithm. 7 This is a preemptive, 
priority-driven algorithm that assigns pri¬ 
orities to tasks according to their dead¬ 
lines. Tasks with earlier deadlines have 
higher priorities. In our version, every task 
is terminated at its deadline even if it is not 
completed at the time. We call this algo¬ 
rithm the ED algorithm. Its complexity is 
0{n log n). In any ED algorithm schedule, 
every task is scheduled in its feasibility 
interval. 

We use the ED algorithm to test whether 
a task set T can be feasibly scheduled. In 
the feasibility test, we schedule the manda¬ 
tory set M using the ED algorithm. If the 
resultant schedule of M is precise, then the 
task set T can be feasibly scheduled. Oth¬ 
erwise, no feasible schedule of T exists. 



Figure 1. An example showing the need for step 3 in algorithm F. 


Identical-weight case. An ED schedule 
of a set of entirely optional tasks is, by 
definition, a feasible schedule of the set. 
Moreover, because such a schedule is pri¬ 
ority-driven, the processor is never left idle 
when there are schedulable tasks. A por¬ 
tion of an optional task is discarded only 
when necessary. Therefore, the ED algo¬ 
rithm is optimal when used to schedule 
optional tasks that have identical weights. 2 

The optimality of the ED algorithm pro¬ 
vides the basis of algorithm F, which 
schedules a set T = { T„ T 2 ,..., T„] of n tasks 
with identical weights on a uniprocessor 
system. We decompose the set T into two 
sets, the set M of mandatory tasks and the 
set O of optional tasks. Algorithm F works 
as follows: 

(1) Treat all mandatory tasks in M as 
optional tasks. Use the ED algorithm to 
find a schedule S, of the set T. If S, is a 
precise schedule, stop. The resultant 
schedule has zero error and is, therefore, 
optimal. Otherwise, carry out step 2. 

(2) Use the ED algorithm to find a 
schedule S m of the set M. If S„ is not a 
precise schedule, T is not schedulable. Stop. 
Otherwise, carry out step 3. 

(3) Using S m as a template, transform S, 
into an optimal schedule S D that is feasible 
and minimizes the total error. 


The example in Figure 1 shows the need 
for step 3. The task set in Figure 1 a consists 
of six tasks of identical weights. Figure lb 
shows the schedules S, and S m generated in 
steps 1 and 2, respectively. S m of the man¬ 
datory set M is precise. Therefore, feasible 
schedules of T exist. 

The schedule S, is, in general, not a fea¬ 
sible schedule of T. Because step 1 treats 
all the tasks as entirely optional, some 
tasks may be assigned insufficient proces¬ 
sor time for their mandatory tasks to com¬ 
plete. In this example, step 1 assigns T 4 
only two units of processor time in S„ which 
is less than the processing time of M t . In step 
3, we transform S, into a feasible schedule 
of T by adjusting the amounts of processor 
time assigned to the tasks, so every task T l 
is assigned at least m, units of processor 
time in the transformed schedule. 

The transformation process in step 3 has 
as inputs the schedules S m and S r Let a, and 
a k+ , be, respectively, the earliest start time 
and the latest finishing time of all tasks in 
the schedule S m . We partition the time in¬ 
terval [a„ a i+1 ] according to S m into k dis¬ 
joint intervals [a p a J+1 ], for/' = 1,2,..., k, so 
in S m the processor is assigned to only one 
task in each of these intervals and is as¬ 
signed to different tasks in adjacent inter¬ 
vals. In the example in Figure 1, k is equal 
to 6, and the time instants a u a 2 ,..., a 7 are 
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Tasks are indexed so that w, > w 2 > ... > w„ 
begin 

Use the ED algorithm to find a schedule S m of M. 

IfS m is not precise, stop; the task set T cannot be feasibly scheduled. 
else 

The mandatory set M' (= [MJ,MJ,..., MJ }) = M 
( = 1 

while (1 <1 i < n ) 

Use algorithm F to find an optimal schedule SJ of M' u {£),}; 

O' = the portion of O, with processing time a," scheduled in SJ 
Ml = M, u O’ 
i = i + 1 
endwhile 

The optimal schedule sought is S„" 
endif 

end algorithm LWF 


Figure 2. Pseudocode for the LWF algorithm. 



0, 3, 7, 9, 13, 15, and 16, respectively. Let 
M(j) denote the mandatory task scheduled 
in the interval [a p a j+l \ in S m , and let T(j) be 
the corresponding task. 

Step 3 adjusts the amounts of processor 
time assigned to the tasks in S,, using S,„ as 
a template. In this step, we scan the sched¬ 
ule S, backward from its end a k+2 . The 
segment of S, after a M is left unchanged. 
We compare in turn, for j = k, k- 1,.... 1, 
the total amounts L,(j) and LJj) of pro¬ 


cessor time assigned to the tasks T(j ) and 
M(j) after a, according to S, and S m , re¬ 
spectively. If L,(j) > LJj), the segment of S, 
in [dj, a J+1 ] is left unchanged. Otherwise, let 
A =LJj)-L,(j). We assign A additional units 
of processor time in [d p a pl ] to T(j). These 
units may be originally assigned to other 
tasks in S r Arbitrarily, we choose some of 
these tasks. We decrease the amounts of 
processor time assigned to them in this 
interval by a total of A units and update 


accordingly the values of L,(0 (for / = 1,2, 
...,/) for all the tasks affected by this re¬ 
assignment. This reassignment can always 
be done because A is less than or equal to 
a J+l - dj and T(j) is ready in the interval. 

In the example in Figure 1, L,(6) and L,(5) 
are left unchanged because they are equal 
to LJ6) and LJ5), respectively. L,(4) is 2 
while LJ4) is 4; therefore, we assign two 
additional units of processor time to T( 4), 
which is T t . These two units of time are 
taken from T 2 . T 2 has three units of proces¬ 
sor time in the interval [9, 13] before the 
reassignment and only one unit after the 
reassignment. The new values of L,(j) are 
5,5,2, and 4 for j = 1, 2, 3, and 4, respec¬ 
tively. Similarly, we compare L,(3) and 
L m (3), and so on. The result of step 3 is the 
optimal schedule S„. 

The complexity of algorithm F is the 
same as that of the ED algorithm, that is, 
0(n log n). Algorithm F always produces a 
feasible schedule of T as long as T can be 
feasibly scheduled — this follows directly 
from the algorithm’s definition. The 
schedule S, obtained in step 1 achieves the 
minimum total error for any set of tasks 
with identical weights. Since step 3 intro¬ 
duces no additional idle time, the total 
error remains minimal. Hence, algorithm F 
is optimal for scheduling tasks with identi¬ 
cal weights to minimize total error. 2 With 
McNaughton’s rule, 8 it can be modified to 
optimally schedule independent tasks with 
identical weights on a multiprocessor sys¬ 
tem containing v identical processors. Then 
its complexity is Olyn + n log n). 

Different-weight case. When tasks in T 
have different weights, we can number 
them according to their weights: w, > w 2 > 
... > w„. Algorithm F is not optimal for 
scheduling tasks with different weights. 
We use the largest-weight-first algorithm, 
which is optimal. Figure 2 shows the LWF 
algorithm in pseudocode. 

Starting from the task with the largest 
weight, in the order of nonincreasing 
weights, the LWF algorithm first finds for 
each task T, in turn the maximum amounts 
of processor time o,° that can be assigned to 
its optional task O,. An optimal schedule is 
a feasible schedule in which the amount of 
processor time assigned to each optional 
task Tg is a 

The LWF algorithm makes use of the 
fact that the amount of processor time a" 
assigned to the only optional task in the set 
M u { O, ) in an optimal schedule of this set 
is as large as possible. (In Figure 2, the 
notation for the optimal schedule of the set 
is SJ.) It uses algorithm F to schedule the 
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tasks in the set M u {O,}. Again, T, is the 
task with the largest weight. In the resul¬ 
tant schedule S„\ the optional task O x is 
assigned the maximum possible amount of 
processor time <J,“. There are optimal 
schedules of T in which O, is assigned o," 
units of processor time. 2 We commit our¬ 
selves to finding one of these schedules by 
combining M t and the portion O' of O, that 
is scheduled in S„' into a task M'. We treat 
the task M' as a mandatory task in the 
subsequent steps. 

In the next step, we again use algorithm 
F to schedule the task set {A#/, A/,,..., M„ } 
u {0 2 }. Let 0 2 ' be the portion of the op¬ 
tional task 0 2 that is scheduled in the re¬ 
sultant optimal schedule S 2 . 0 2 ' has the 
maximum possible amount of processor 
time o 2 °. There are optimal schedules of T 
in which the amounts of processor time 
assigned to O, and 0 2 are a," and a 2 °, re¬ 
spectively. We commit ourselves to find¬ 
ing one of these schedules by combining 
M, and 0 2 ' into the mandatory task M 2 . 

We repeat these steps for i = 3, 4, .... n 
until all a," are found. The schedule S" 
found in the last step is an optimal schedule 
of T with minimum total error. 

The time complexity of the first step 
when algorithm F is used is 0(n log n), but 
in subsequent steps, algorithm F requires 
only 0(n ) time. Hence, the time complex¬ 
ity of the LWF algorithm is 0(n 2 ). 

Figure 3 shows how the LWF algorithm 
works. Figure 3a lists four tasks and their 
weights. Figure 3b shows the schedule S m 
of M u {O,) produced by algorithm F. We 
commit ourselves to finding an optimal 
schedule in which the amount of processor 
time assigned to O, is 6. This is an earliest- 
deadline-first schedule, and we use it in the 
second step as a template to find an optimal 
schedule of the task set {A//, T 2 , M 3 , Af,}. 
Figure 3b shows the resultant schedule S 0 . 
The total error of the tasks is 25. Also 
shown is a schedule S u , which minimizes 
the unweighted total error. 

Scheduling periodic 
jobs 

In the well-known periodic-job mod¬ 
el, 3 - 6 there is a set J of n periodic jobs. Each 
job consists of a periodic sequence of re¬ 
quests for the same computation. The peri¬ 
od 71, of a job 7, in J is the time interval 
between two consecutive requests in the 
job. In terms of our basic model, each 
request in job 7, is a task whose processing 
time is x,-. The ready time and deadline of 


the task in each period are the beginning 
and the end of the period, respectively. 
Therefore, we can specify each job 7, by the 
two-tuple (7t„ T f ). In the extended-work¬ 
load model used to characterize periodic 
imprecise computations, 3 each task in 7, 
consists of a mandatory task with process¬ 
ing time m, and an optional task with pro¬ 
cessing time t ; - m t . The optional task is 
dependent on the mandatory task. In other 
words, we decompose each job 7, = (ji„ X,) 
into two periodic jobs: the mandatory job 
M, = (jt„ m,) and the optional job O t = (n„ x, 
- m,). The corresponding sets of mandato¬ 
ry jobs and optional jobs are denoted by M 
and O, respectively. Let 

u=p i m i 

denote the utilizationfactor of the job set J. 
U is the fraction of processor time required 
to complete all the tasks in J if every task 
is completed in the traditional sense. Sim¬ 
ilarly, let 

« = ±rnjn k 

Here, u is the utilization factor of the man¬ 
datory set M. 

Because the worst-case performance of 
priority-driven strategies for scheduling 
periodic jobs on multiprocessor systems is 
unacceptably poor, it is common to assign 
jobs once and for all to processors, and 
schedule the jobs assigned to each proces¬ 
sor independently of the jobs assigned to 
the other processors. We can formulate the 
problem of finding an optimal assignment 
of jobs to processors and using a minimum 
number of processors as a bin-packing 
problem. 

A heuristic job-assignment algorithm 
with reasonably good worst-case perfor¬ 
mance is the rate-monotone next-fit (or 
first-fit) algorithm. According to this algo¬ 
rithm, jobs in J are sorted in the order of 
nonincreasing rates and are assigned to the 
processors on the next-fit (or first-fit) ba¬ 
sis. A job fits on a processor if it and the 
jobs already assigned to the processor can 
be feasibly scheduled according to the rate- 
monotone algorithm. 6 (The rate-monotone 
algorithm is a preemptive, priority-driven 
algorithm that assigns priorities to jobs 
according to their rates: the higher the rate, 
the higher the priority.) When deciding 
whether an imprecise job fits on a proces¬ 
sor, the algorithm considers only the man¬ 
datory set M. Let a, = m,/7i,. Suppose that k 
jobs are already assigned to a processor, 
and their mandatory jobs have a total utili¬ 
zation factor 


u = p, 

If an additional job J M is also assigned to 
this processor, the total utilization factor of 
thefc+ 1 mandatory jobs is u+m k+] /n k+l .J M 
is assigned to the processor only if 

u + m k Jn k+l <{k+\ )(2 w<m > - 1) (3) 

Hereafter, J denotes the set of n jobs 
assigned to one processor in this manner. 
The utilization factor U of the job set J may 
be larger than n(2 l,n - 1). Consequently, J 
may not be precisely schedulable to meet 
all deadlines according to the rate-mono- 
tone algorithm. However, the utilization 
factor u of the mandatory set is less than 
n(2 u " - 1). Hence, the mandatory set M is 
always precisely schedulable. 6 Since the 
value of u is less than 1 (for example, 0.82 
for n = 2 and In 2 for large n), a fraction of 
processor time is always available to exe¬ 
cute tasks in the optional set O. 

Depending on the kind of undesirable 
effect that errors cause, applications can be 
classified as either error-noncumulative or 
error-cumulative. Different performance 
metrics are appropriate for each. 

For an error-noncumulative application, 
only the average effect of errors in differ¬ 
ent periods is observable and relevant. 
Optional tasks are truly optional because 
none need to be completed. Image en¬ 
hancement and speech processing are ex¬ 
amples of this type of application. 

In contrast, for an error-cumulative ap¬ 
plication, errors in different periods have a 
cumulative effect. The optional task in one 
period among several consecutive periods 
must be completed within that period and, 
hence, is no longer optional. Tracking and 
control are examples of this type of appli¬ 
cation. 

The complexity of scheduling error-cu¬ 
mulative jobs and an approximate algo¬ 
rithm for scheduling them with identical 
periods have been discussed elsewhere. 3 
Much work remains in finding effective 
algorithms and schedulability criteria for 
scheduling error-cumulative jobs that have 
arbitrary periods and error characteristics. 
The workload on practical systems typical¬ 
ly is a mixture of error-cumulative jobs, 
error-noncumulative jobs, aperiodic jobs, 
and dependent jobs. Programmers need 
good heuristic algorithms for scheduling 
such complex job mixes. 

Error-noncumulative jobs. Now, we 
focus on error-noncumulative jobs. Since 
each periodic job can be viewed as an 
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Figure 4. Scheduling error-noncumulative jobs. 


infinite chain of tasks, the total error de¬ 
fined in Equations 2a and 2b is infinite for 
an imprecise schedule. A more appropriate 
performance metric of the overall result 
quality is the average error in the results 
produced in several consecutive periods. 
While the duration over which the average 
error is computed can be arbitrary, a con¬ 
venient choice of this duration is 7t, the least 
common multiple of all the periods in J. For 
this duration, the average error eof at any 
time is the average value of EfOj - a w ) over 
the past 7t/7l, periods, where O lV is the amount 
of processor time assigned to the task in the 
y'th period of J,. Again, the error function 
£,(Oy) is a nonincreasing function of <3 tJ . The 
average error over all jobs in J is 

where w, is a nonnegative constant weight 
and 

i *.- 1 

A class of heuristic algorithms for 
scheduling error-noncumulative periodic 
jobs on uniprocessors to minimize the av¬ 
erage error has been designed and evaluat¬ 
ed. 3 All the algorithms in this class are 
preemptive and priority-driven, and all use 
the same strategy: They execute optional 
tasks only after all the ready mandatory 
tasks have completed. Specifically, given 
a job set J and its associated mandatory set 
M and optional set O, all the jobs in M have 
higher priorities than all the jobs in O. 
Moreover, the rate-monotone algorithm 
schedules jobs in M precisely. Because of 
the condition given by Equation 3, the set 
M can always be feasibly scheduled. 6 Such 
algorithms meet all the deadlines, regard¬ 
less of how jobs in O are scheduled. 

Figure 4 shows an example in which the 


job set J consists of four jobs. They are (2, 
1), (4, 0.5), (5, 0.5), and (6, 1.5), and their 
mandatory tasks have processing times 0.5, 
0.2,0.1, and 1.0, respectively. The utiliza¬ 
tion factor of the job set J is 0.975. J is not 
precisely schedulable according to the 
rate-monotone algorithm. In a rate- 
monotone schedule, the task in the first 
period of J A misses its deadline. However, 
the mandatory set M consists of (2, 0.5), 
(4,0.2), (5,0.1), and (6,1.0) with a utiliza¬ 
tion factor 0.4867. It is precisely schedula¬ 
ble according to the rate-monotone 
algorithm. 

White boxes in the timing diagram in 
Figure 4 show the time intervals when the 
processor is assigned to tasks in M in a rate- 
monotone schedule of M. Black bars indi¬ 
cate the time intervals during which the 
processor is assigned to jobs in the optional 
set O, consisting of (2, 0.5), (4, 0.3), (5, 
0.4), and (6, 0.5). 

Types of heuristic algorithms. The 

heuristic algorithms 3 differ only in how 
they assign priorities to optional jobs. Some 
make priority assignments to optional tasks 
on the basis of error function behavior. 
Examples include the least-utilization al¬ 
gorithm, the least-attained-time algorithm, 
and the first-come-first-serve algorithm. 

The least-utilization algorithm statical¬ 
ly assigns higher priorities to optional jobs 
with smaller weighted utilization factors: 
(t ; - m t )/ 7 l,w,. It minimizes the average er¬ 
ror when the error functions Efx) are linear 
and when all jobs have identical periods 
and weights. 

At any time, the least-attained-time al¬ 
gorithm assigns the highest priority to the 
optional task that has attained the least 
processor time among all the ready option¬ 
al tasks. This algorithm tends to perform 
well when the error functions E,(x) are 


convex, that is, when the error in the result 
decreases faster earlier and more slowly 
later, as the computation proceeds. 

The first-come-first-serve algorithm 
performs well when the error functions 
Efx) are concave, that is, when the under¬ 
lying procedure converges more slowly 
earlier and faster later, as the computation 
proceeds. 

When we do not know the exact behav¬ 
ior of the error function, we can use an 
algorithm that ignores the error functions 
in assigning priorities to optional tasks. 
The shortest-period algorithm, which also 
assigns priorities to optional jobs on a rate- 
monotone basis, is such an algorithm. 

Another example is the earliest-dead- 
line algorithm. This algorithm assigns pri¬ 
orities dynamically to optional tasks ac¬ 
cording to their deadlines: the earlier the 
deadline, the higher the priority. If any of 
the heuristic algorithms we have described 
here can precisely schedule a set of jobs, 
the earliest-deadline algorithm can pre¬ 
cisely schedule it, too. 3 

Quantitative data on achievable average 
errors with the algorithms described above 
for different values of the utilization fac¬ 
tors of M and J are available elsewhere. 3 
These algorithms have the advantage of 
the rate-monotone algorithm: Tasks miss 
deadlines in a predictable manner during a 
transient overload. Like the classical ear¬ 
liest-deadline-first algorithm, these algo¬ 
rithms also use the processor to its fullest 
extent. They are ideal for applications where 
transient overloads occur frequently or 
actual task processing times vary widely. 
Usually the average error remains toler¬ 
ably small when U becomes larger than 1 
and no classical algorithm can schedule the 
tasks satisfactorily. 

The advantages are realized at the ex¬ 
pense of not being optimal. For example, 
these algorithms may lead to schedules 
with a nonzero average error for job sets 
that can be precisely scheduled to meet 
deadlines by the classical rate-monotone 
or earliest-deadline-first algorithms. 

Scheduling 
parallelizable tasks 

A task is parallelizable if it can be exe¬ 
cuted in parallel on a number of processors 
to complete in less time. The degree of 
concurrency of any task in an interval re¬ 
fers to the number of processors on which 
the task executes in parallel in the interval. 
In our model of parallelizable tasks, the 
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degree of concurrency of any task may 
change during its execution. 

The parameters that characterize each 
parallelizable task T, in a set T of n tasks 
include its ready time deadline d : , pro¬ 
cessing time T f , and weight w, — in short, 
the parameters that characterize any se¬ 
quential task. A parallelizable task also has 
the following two parameters: 

• Maximum degree of concurrency C„ the 
number of processors on which T, can 
execute in parallel 

• Multiprocessing overhead factor 0„ a 
proportional constant used to compute 
the overhead in the parallel execution 
of T, 

Like sequential tasks, each paralleliz¬ 
able task 7) is logically composed of a 
mandatory task M, and an optional task 0„ 
whose processing times on a single pro¬ 
cessor are m, and o„ respectively. In this 
section we use task to refer to a parallelizable 
task. We consider only cases where the 
tasks are independent. 

A parallel schedule of the task set T on 
a system containing v identical processors 
assigns no more than one task to any pro¬ 
cessor at any time and assigns each task T l 
to at most C, processors. For a given a task 
set T, let a = {a,, a 2 , ..., a M ] be an in¬ 
creasing sequence of distinct numbers ob¬ 
tained by sorting the list of ready times and 
deadlines of all the tasks in T and deleting 
duplicate entries in the list. (Here k + 1 < 
2 n.) This sequence divides the time be¬ 
tween the earliest ready time a, and latest 
deadline a k+l into k intervals/, = [a } ,a j+l ] for 
y=l,2,..., k. 

We divide the problem of finding feasi¬ 
ble parallel schedules of T into two sub¬ 
problems: the time allocation problem and 
the schedule construction problem. To solve 
the time allocation problem, we decide 
how many units of processor time in each 
of the k intervals Ij should be allocated to 
each task T : , so the tasks meet their timing 
constraints and the total error is minimized. 
Given this solution, we then solve the sec¬ 
ond problem to obtain a parallel schedule 
on v processors. 

Time allocation problem. When a sys¬ 
tem executes a task in parallel on more than 
one processor, it wastes some processor 
time in interprocessor communication and 
synchronization. This multiprocessing 
overhead 0, of a task T, in any time interval 
depends on the task’s degree of concurren¬ 
cy c, and, consequently, on the amount of 


minimize^, {t, -£[*,(>):-0,(/)]l 

Xx f (y)ST i + X e -0') 


i>,(/)sm,+f 0,( 7) 

7=1,2. n 

vt,>^x,U) 

/*1,2, ... ,k 

(c f -i)>y(x,.(7))>o 

X,(7)S0 

£=1,2,...,/? 

7*1,2. n 

7=1,2. k 


Figure 5. Linear programming formu¬ 
lation. 


processor time allocated to the task in the 
interval. 

Studies on scheduling parallelizable 
(precise) tasks typically assume that for c, 
larger than 1, 0, is either a positive con¬ 
stant or a monotone nondecreasing func¬ 
tion of c,. We present a special case where 
the multiprocessing overhead is a linear 
function of the degree of concurrency. This 
assumption allows us to formulate the time 
allocation problem as a linear program¬ 
ming problem and solve it using any of the 
well-known techniques." 

To calculate the multiprocessing over¬ 
head, we suppose that a task T) is allocated 
a total of x units of processor time on all 
processors in an interval of length t. If x < 
t, this task is not parallelized in this inter¬ 
val, and its multiprocessing overhead in 
this interval is zero. If x > t, the minimum 
degree of concurrency of the task in this 
interval is \xl t~\. Rather than make the 
multiprocessing overhead proportional to 
this nonlinear function of x, we let the 
multiprocessing overhead of 7) in this in¬ 
terval be proportional to Y(x) = ma x(x/t- 1, 
0). Then Q,Y(x) units of processor time is 
wasted as the multiprocessing overhead. 

The actual amount of processor time 
available to the task in this interval for its 
execution toward completion is x - 0,T(x). 
We say that this amount of processor time 
is actually assigned to the task 7). Again, 
Equations 2a and 2b give us the error e, of 
a task Ti in terms of the amount c, of pro¬ 
cessor time actually assigned to its option¬ 
al task 0, in all k intervals. 

Let tj denote the length of the interval /,, 
and XjiJ) denote the amount of processor 
time allocated to the task 7’ in Ij. Here x,(j) 
is zero if the feasibility interval of T, does 


not include the interval /,. Let 

0,0) = Q,y(xi(j)) = 0, max(x,0)/r -1,0) 

be the multiprocessing overhead of 7] in¬ 
curred in this interval when its allocated 
processor time is x,(j). 

Figure 5 gives the linear programming 
formulation of the processor time alloca¬ 
tion problem. We want to find the set (xfj )} 
that minimizes the objective function, the 
total (weighted) error expressed here in 
terms of xfj). The first set of constraints 
specifies that the total processor time allo¬ 
cated to every task in all k intervals is no 
more than its processing time T, plus its total 
multiprocessing overhead. These con¬ 
straints ensure that no task gets more pro¬ 
cessor time than its processing time. The 
second set of constraints specifies that the 
total processor time allocated to every task 
7, in all k intervals is no less than the sum 
of the processing time m, of the mandatory 
task Mi and the total multiprocessing over¬ 
head. These constraints ensure that the 
schedule assigns sufficient processor time 
to every mandatory task for it to complete 
in the traditional sense. Together, they en¬ 
sure that we can construct a valid schedule 
from the resultant set X = {x,(/)} of pro¬ 
cessor time allocations. 

The third set of constraints requires that 
the total processor time allocated to all 
tasks in every interval Ij is no greater than 
the total amount of processor time avail¬ 
able on all v processors. The fourth set of 
constraints ensures that the degree of con¬ 
currency of each task is at most equal to its 
maximum degree of concurrency. The fifth 
set states that every x,(j) is nonnegative. 

The optimal solution of this linear pro¬ 
gram, if one exists, gives a set X of pro¬ 
cessor time allocations from which we can 
construct a feasible parallel schedule of T 
with the minimum total error. The com¬ 
plexity of the processor time allocation 
problem is the same as the complexity of 
the most efficient algorithm for linear pro¬ 
gramming." One efficient algorithm for 
linear programming requires 0((a + P)P 2 + 
(a + P) I 5 P) operations, where a is the 
number of inequalities and P is the number 
of variables. For our problem, oc is equal to 
3 n + k, and P is at most equal to nk. 

In the example in Figure 6, there are 
three tasks; Figure 6a lists their parame¬ 
ters. Their ready times and deadlines di¬ 
vide the time between 0 to 14 into four 
intervals beginning at 0, 4, 6, and 12. The 
values of tj for j = 1, 2, 3, and 4 are 4, 2, 6, 
and 2, respectively. Figure 6b shows the 
solution of the corresponding linear pro- 
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Figure 6. An example of processor time allocation. 


gram. A blank entry at a row T, and a col¬ 
umn xfj) indicates that the feasibility in¬ 
terval of T : does not include the interval [a fi 
a J+1 ]. To save space in the tabulation. Fig¬ 
ure 6b lists Y(x ; (j)) simply as Yj. The total 
error of the feasible schedule is 19. 

Schedule construction. The solution of 
the linear program is the set X = {Jc,(/’)} of 
processor time allocations, which gives us 
the amounts of processor time allocated to 
the n tasks in T in each time interval I t . Given 
X, we need to decide which task is to run on 
which processor(s) in each interval l p so we 
can construct a parallel schedule. A 
straightforward approach is first to con¬ 
struct independently a segment of the par¬ 
allel schedule in each interval l s on the ba¬ 
sis of the processor time allocations x t (j) for 
the interval. After constructing the sched¬ 
ule segments in all k intervals, we re¬ 
arrange the order in which tasks are as¬ 
signed in adjacent segments to reduce the 
total number of preemptions and migra¬ 
tions. If a task is scheduled in two adj acent 
segments on two different processors, in 
this rearrangement step we move them 
whenever possible so they are scheduled 
contiguously on the same processor(s) in 
these segments. To do this, we can use an 
0(n 2 log n) algorithm based on a solution 
of the bipartite matching problem. 

Returning to how to construct a parallel 
schedule segment from the processor time 
allocations of an interval Ij, we consider now 
the first interval /,. Segments in the other 


intervals can be constructed in the same 
manner. Without loss of generality, let T,, 
T 2 , ... T, be all the tasks allocated nonzero 
processor time in this interval. The portion 
of each task T, assigned in /, is divided into 
v ; = U(l)/t,J subtasks with processing 
time t, and a fractional subtask with pro¬ 
cessing time t|/, = t, - U(l)/f.J f i- After all 
the subtasks with processing time t, are 
assigned on 

i>, 

processors, we try to pack the / fractional 
subtasks on the remaining processors. We 
can use a pseudopolynomial algorithm for 
this knapsack problem. 

Queuing-theoretical 

formulation 

A performance metric common in many 
applications is the average response time 
of tasks, that is, the average amount of time 
between the instant when a task is ready 
and the instant at which the task is complet¬ 
ed (and leaves the system). The section on 
imprecise scheduling briefly describes the 
deterministic formulation of the problem: 
Find optimal schedules with the minimum 
average response time, subject to the con¬ 
straint of a maximum acceptable total er¬ 
ror. This problem is NP-hard 10 for most 
practical cases, so the queuing-theoretical 


approach is more fruitful than the deter¬ 
ministic formulation. Here we briefly de¬ 
scribe two queuing-theoretical formula¬ 
tions. 

The simplest model of an imprecise 
multiprocessor system with v identical 
processors is an open v-server Markov 
queue. Tasks arrive and join a common 
queue according to a Poisson process with 
an average rate of X. They are serviced (that 
is, executed) on a first-come-first-serve 
basis. The processing times (that is, ser¬ 
vice times) of all tasks are exponentially 
distributed. (Later, we say more about this 
assumption.) This simple Markov multi¬ 
server queue is analytically tractable. For 
most practical cases, however, it models 
imprecise computation systems in suffi¬ 
cient detail to provide the performance 
data we need to choose design parameters 
of imprecise service disciplines. 

First, we consider imprecise computa¬ 
tions implemented by providing two ver¬ 
sions of each task. A task is serviced at the 
full level when its primary version is 
scheduled and executed, or at reduced lev¬ 
el when its alternate version is scheduled 
and executed. When the system has a light 
load and the response time is small, it 
services every task at the full level. When 
the load becomes heavy, the system reduc¬ 
es the overall response time by servicing 
some tasks at the reduced level. Such a 
scheduling scheme is called a two-level 
scheduling discipline.' 2 The full-level 
processing times of all tasks are statistical- 
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ly independent, exponentially distributed 
with a mean of 1/p.. The reduced-level 
processing time of a task is a constant 
fraction y of its full-level processing time, 
where y is a real number between 0 and 1. 
Let p = A7vp denote the offered load of a 
processor in the system, that is, the fraction 
of time each processor is busy if all tasks 
are serviced at their full level. It is easy to 
see that the system is not saturated as long 
as p < 1/y. 

Here y is a design parameter of an impre¬ 
cise computation system. We assume that 
the larger y is, the better the result quality 
of the tasks that are serviced at the reduced 
level. A design parameter of the two-level 
service discipline is the threshold H: As long 
as the number of tasks in the system is less 
than H, the system load is light. For a given 
y, we choose the value of H to achieve a 
desired trade-off between the average 
waiting time and the average result quality. 
The trade-off reduces the average waiting 
time W of tasks — the average time a task 
spends in the queue before its execution 
begins. 

Thus Wplus the average processing time 
of the tasks corresponds to the mean flow 
time F defined in the section on imprecise 
scheduling problems. We can minimize it 
easily by servicing every task at the re¬ 
duced level. Therefore, we must consider 
the cost of this trade-off. Studies on the 
two-level scheduling discipline 12 measure 
this cost in terms of the average result 
quality, the average fraction G of tasks 
serviced at the full level. G measures the 
system’s quality of service. In the steady 
state, G = (t/-yp)/(l -y)p, where U is the 
average utilization of each processor. 

We choose H on the basis of the perfor¬ 
mance data on W and G. Such data on two- 
level scheduling in uniprocessor systems 
are available elsewhere. 12 More recently, 
we evaluated the performance of imprecise 
multiprocessor systems. The results indi¬ 
cate that an appropriate choice of H makes 
an imprecise system \yith a two-level 
scheduling discipline perform almost as 
well as the corresponding precise system 
in terms of the average service quality, 
when the offered load of the system is 
small. When the offered load is high, the 
two-level scheduling scheme can signifi¬ 
cantly improve the average task waiting 
time by sacrificing service quality. This 
trade-off is most effective when the of¬ 
fered load per processor is near 1. While 
the average waiting time in a precise sys¬ 
tem approaches infinity, the two-level 
scheduling scheme keeps the average 
waiting time in an imprecise system small. 


with a reasonably small decrease in the 
average service quality. 

An imprecise computation system that 
uses monotone tasks is more appropriately 
modeled as an open MIE K+i lv queue. Each 
task T, is composed of a mandatory task A/, 
followed by K optional tasks O u . (In the 
deterministic models discussed in earlier 
sections, K is at most equal to 1.) Let o Q 
denote the processing time of O ir The 
processing time T, of the task T t is given by 

L-=m,■ + !>,■ 

The processing times m, of the mandatory 
tasks, as well as the o y , are all statistically 
independent and exponentially distributed 
random variables. 

When a monotone imprecise system is 
overloaded, it may discard a number* (x < 
K) of optional tasks in some task or tasks in 
the system. The decrease in result quality 
can be quantified in part by the fraction of 
optional tasks that the system discards. 
The expected value of this fraction gives a 
rough measure of the average error e in the 
task results. 

Since the system can discard a variable 
number of optional tasks in each task, the 
average error does not give us a complete 
picture of the incurred cost. Another cost 
function is the imprecision probability, the 
probability of any task being imprecise 
because the system discarded some of its 
optional tasks. We are studying the depen¬ 
dence of these cost factors on parameters 
K, x, and H of the monotone imprecise 
system. 

A direction of our future study concerns 
the way a system determines the kind of 
service each task receives. Past studies on 
two-level scheduling disciplines assume 
that the system checks the number of its 
tasks at each instant immediately before a 
processor begins to execute a task. 12 The 
system services the task at the head of the 
queue at full level if its load is light, and at 
the reduced level otherwise. In other words, 
the system is reasonably responsive to 
overload conditions. 

Similarly, we have proposed that in 
monotone imprecise systems, the system 
could check the total number of tasks in the 
queue at each instant when a new task 
arrives and immediately before it begins to 
service a task. As long as the queue length 
is equal to or greater than H, the system 
discards * optional tasks in the tasks being 
served. This scheme, called the responsive 
service scheme, is highly responsive to 
overloads: The system does very well in 
reducing its backlog and clearing up the 


overload whenever such a condition oc¬ 
curs. However, it cannot guarantee service 
quality. A task that arrives when the sys¬ 
tem is lightly loaded may have its optional 
tasks discarded if the system becomes 
overloaded during the time the task waits 
in the system. 

With the guaranteed-service scheme, on 
the other hand, the system checks its total 
number of tasks at each arrival instant. It 
tags for reduced service a task arriving 
when H or more tasks are in the queue. The 
tasks already in the system before the over¬ 
load are fully serviced to completion. With 
this scheme, an imprecise system does not 
respond as quickly as possible to correct an 
overload. However, the quality of results 
produced by tasks arriving to the system 
when it is not overloaded is guaranteed to 
be good. This scheme is good for applica¬ 
tions in which overloads can be cleared 
quickly. 


W e have reviewed different ap¬ 
proaches for scheduling im¬ 
precise computations in hard 
real-time environments. We also described 
several imprecise computation models that 
explicitly quantify the costs and benefits in 
the trade-off between result quality and 
computation time requirements. An impre¬ 
cise computation scheduler must balance 
the benefit in enhanced system response 
with the cost in reduced result quality. 

Because the criteria for measuring costs 
and benefits vary according to application, 
there are many different imprecise sched¬ 
uling problems. We have presented our 
recent progress toward solving some of 
these problems, and the directions we plan 
to take in our future work on each of these 
problems. ■ 
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Building Flexible Real-Time 
Systems Using the Flex 
Language 


Kevin B. Kenny and Kwei-Jay Lin 
University of Illinois at Urbana-Champaign 


A real-time computation must be 
completed by a deadline and, 
unlike nonreal-time computation, 
must simultaneously satisfy both function¬ 
al and temporal correctness criteria. Fail¬ 
ure to satisfy either criteria makes the re¬ 
sult unacceptable. 

Real-time systems usually consist of 
many real-time computations with differ¬ 
ent but related deadlines. These computa¬ 
tions must be scheduled so all deadlines 
are met. To ensure that a real-time program 
meets its specification, a real-time pro¬ 
gramming language must 

• have the capacity to express different 
types of timing requirements, 

• provide mechanisms for runtime sys¬ 
tems to enforce timing constraints, and 
• be based on a model that makes it 
easier to ensure the program’s tempo¬ 
ral correctness. 

If either the complexity of a computation 
or the available resources can vary, meet¬ 
ing deadlines becomes especially difficult. 
The complexity of many common compu¬ 
tational operations, such as searching, 
sorting, and matrix-inversion, is data- 
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Programs in real-time 
systems have stringent 
timing requirements. 
The Flex programming 
language makes it 
possible to program 
real-time systems that 
can respond to 
dynamic environments 
to make sure critical 
deadlines are met. 


dependent. In addition, the resources 
available for a computation can differ in 
systems with a variable amount of resources 
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as in many fault-tolerant systems. For these 
types of applications, the language used 
for system implementation must provide 
powerful and flexible primitives to ensure 
that deadlines will be met, even in a worst- 
case scenario. 

Our approach to implementing flexible 
real-time systems is to design computa¬ 
tions whose execution times can be adjust¬ 
ed so all important deadlines are guaranteed 
to be met under all circumstances. One way 
to do this is to allow computations to return 
imprecise results. 

In many hard real-time applications, 
obtaining an approximate result before the 
deadline is much more desirable than ob¬ 
taining an exact result after the deadline. 
We have identified several classes of 
computations that can flexibly adapt them¬ 
selves to produce faster but less precise 
results. 

Another approach is to provide multiple 
implementation versions for a computation, 
each with a different performance capaci¬ 
ty. As soon as the timing constraint can be 
determined for the computation, one of the 
versions is selected to produce a result 
before the deadline. 

This article presents the design and im- 
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plementation of a real-time programming 
language called Flex, 1 which is a deriva¬ 
tive of C++. We describe how different 
types of timing requirements might be ex¬ 
pressed and enforced in Flex, how they 
might be fulfilled in a flexible way using 
different program models, and how the 
programming environment can help in 
making binding and scheduling decisions. 
The article also presents a real-time pro¬ 
gramming environment. 

In designing Flex, our goal was not to 
implement yet another programming lan¬ 
guage. Rather, we were interested in the 
general real-time programming primitives 
that can be added to most existing nonreal¬ 
time languages. 

Issues in programming 
real-time systems 

To date, four approaches to programming 
real-time systems have been identified. The 
first approach is to program in assembler 
or other low-level languages. These pro¬ 
grams are not only difficult to write but are 
also difficult to modify, reuse, or port. 
Exhaustive trial-and-error testing is need¬ 
ed to establish that they meet timing re¬ 
quirements. 

Another approach is to use languages 
such as Ada and Modula-2, which are pri¬ 
marily general-purpose programming lan¬ 
guages. The programmer writes a logically 
correct program, using mechanisms such 
as coroutines, processes, priorities, inter¬ 
rupts, and exception handling to control 
the execution behavior. Knowledge of the 
runtime environment is required to tailor 
the program to meet timing specifications, 
but this makes the program sensitive to 
hardware characteristics and system con¬ 
figuration. 

A third approach, as in Real-Time Eu¬ 
clid, 2 restricts the constructs provided in 
the language to those that are time-bound¬ 
ed. The programmer cannot use recursion, 
dynamic memory allocation, or dynamic 
process instantiation because their execu¬ 
tion time is unpredictable. These restric¬ 
tions make it easier to estimate the execu¬ 
tion time of the program, and this 
information facilitates scheduling to meet 
deadlines. However, writing programs 
becomes more difficult with a restricted set 
of constructs. 

The fourth approach, adopted in pro¬ 
gramming languages such as Esterel, 3 
permits direct expression of timing re¬ 
quirements. The program specifies the 


deadlines for procedures and largely leaves 
ensuring that the requirements are met to 
the runtime system. Rather than requiring 
that all timing behavior be known at com¬ 
pile time, they permit the programmer to 
specify not only the timing requirements 
but also exception handlers to be executed 
if the timing requirements are not met. The 
lack of compile-time analysis, however, 
means that predictability, in the strong sense 
of completing without exception, is lost. 

Each of the approaches described above 
has its merits, but none is totally satisfac¬ 
tory. In this section, we review some of the 
issues involved in programming real-time 
systems. For each issue, we also identify 
our proposed solution. 

Scheduling real-time systems. Many 
traditional real-time systems have been 
programmed to be as fast as possible, 
without formal assurance that performance 
will be equal to the requirements. In early 
real-time systems, this haphazard method 
was workable, since the tasks were so simple 
that the performance of the computer sys¬ 
tem was not taxed. 

Today, more severe timing requirements 
are placed on real-time systems, demand¬ 
ing more effort on the part of the system 
designer to ensure that all deadlines are 

The issue of scheduling computations so 
all deadlines are met is central to this 
problem. Frequently, this scheduling 
problem is resource constrained. In addi¬ 
tion to meeting deadlines, the schedule has 
to be organized so tasks will fit within the 
scarce computational resources available. 

Resource-constrained scheduling is 
usually a computationally intractable 
problem. Even in the simple case of a 
number of tasks with deadlines that must 
fit in a limited amount of memory, the 
problem is /VP-complete. 

Our solution is to accept the computa¬ 
tional intractability and provide for flexi¬ 
ble trade-offs among time, precision, and 
resources. Instead of carrying out tasks 
that require a fixed amount of space and 
time, we do each task as (a set of) compu¬ 
tations that can be executed using a flexi¬ 
ble amount of time. This produces results 
with various degrees of precision or con¬ 
sumes different amounts of resources. 

What makes this approach feasible is 
that, generally, a basic schedule in which 
all computations meet deadlines can be 
easily found if each task only needs a 
minimum degree of precision or consumes 
a minimum amount of resources. In this 
basic schedule, however, extra time and 


resources are usually available in the sys¬ 
tem for the computations. We can then use 
the extra time and resources and find a 
better schedule with more precise results. 

Timing constraint systems. To carry out 
our proposed scheduling approach, there 
must be a way to define the constraints on 
time and resources to the computations. 
Some notion of a “constraint” must there¬ 
fore be part of the system. Allen presented 
a consistent theory of timing constraints in 
his study of how to maintain knowledge 
about the temporal ordering of a set of 
actions using temporal logic. 4 He repre¬ 
sents each action as taking place in an 
interval of time and defines seven relations 
between intervals that describe the syn¬ 
chronization of one event with respect to 
another. These relations correspond to in¬ 
tuitive notions, such as “A takes place be¬ 
fore B,” “A and B begin and end at the same 
time,” and “A takes place during the time 
that B does.” 

Dasarathy was one of the first research¬ 
ers to describe timing constraints in a manner 
consistent with the logic used in the Flex 
language. 5 He constructed a language called 
the Real-Time Requirements Language. In 
his scheme, timing constraints could express 
the minimum or maximum time allowed 
between the occurrence of stimuli S, ac¬ 
tions in the outside world, and responses R, 
the completion of the actions that a system 
takes. All four combinations S - S,S - R, 
R- S, and R - R could be specified. 

Constraints on the time before a stimu¬ 
lus were constraints on the behavior of the 
outside world. Constraints on the time before 
a response were interpreted as constraints 
on the amount of time that the system could 
use to process the corresponding stimuli. 
Dasarathy ’ s RTRL was a specification lan¬ 
guage and was not intended for automatic 
processing. 

The Real-Time Logic scheme by Jahanian 
and Mok 6 was similar. In it, events and 
actions corresponding more or less to 
Dasarathy’s stimuli and responses were 
identified. To describe periodic events, 
Jahanian and Mok used an occurrence 
function to specify the ith occurrence of a 
repeated event. A mechanized inference 
procedure, the first of its kind, was presented 
to perform automatic reasoning about timing 
properties, and the events and responses 
could be associated by annotation with 
program constructs. 

Flex includes a constraint mechanism as 
a basic programming primitive. User-de¬ 
fined constraints, including timing con¬ 
straints, can be associated with a block of 
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statements. Although not as powerful as 
RTL, Flex timing primitives are able to 
carry out most of the relationships that can 
be defined by RTRL. We discuss our con¬ 
straint block structure in the Flex timing 
mechanism section. 

Predicting program performance. To 

verify if timing constraints can be satisfied, 
we must be able to predict a program’s 
performance. The time-honored method of 
determining the performance behavior of a 
program is to run it, either on the target 
hardware or on a simulator that models the 
hardware. The simulation or test run must 
be presented with data and/or stimuli rep¬ 
resentative of those that will be seen in 
actual service of the system. 

The problem with this approach is that 
the testing is limited and generally cannot 
include the entire set of possible inputs. 
The worst case for the consumption of time 
or some other resource might not be un¬ 
covered in testing. Moreover, if a simula¬ 
tor is used, an uncertainty might exist that 
the simulator actually reflects the perfor¬ 
mance of the underlying hardware. 

For this reason, designers of real-time 
languages have generally preferred to 
conduct analyses that examine a form of 
the program code and try to prove assertions 
about the program’s performance behavior. 
Leinbaugh conducted one of the first at¬ 
tempts to characterize the performance of 
high-level programs. 7 For such an early 
project, his work was remarkably thorough. 
The work characterized the time required 
by a higher level construct in terms of its 
CPU time, time spent waiting to enter a 
critical section, time spent ready and waiting 
for a processor, time spent performing I/O, 
and time spent waiting at a synchronization 
point. Conservative bounds for all of these 
quantities were estimated. 

Leinbaugh’s work, and all similar sys¬ 
tems using code analysis, cannot solve the 
general problem of determining execution 
time for all programs. The problem is un- 
decidable, being equivalent to the halting 
problem. Real-Time Euclid 2 made the 
analysis easier by forbidding many pro¬ 
gramming constructs, including While loops 
(only counted loops were allowed), recur¬ 
sion, and recursive data structures such as 
linked lists. The timing tools built at the 
University of Texas at Austin 8 allow While 
loops, but the programmer must supply the 
worst-case number of iterations of each 
unbounded loop using a separate timing 
analysis language. 

We took an alternative approach based 
on program measurements. Our approach 


alleviates some of the objections to pro¬ 
gram measurements by showing how sta¬ 
tistical confidence in the program’s per¬ 
formance behavior can be achieved. It also 
allows actual behavior — not just worst- 
case performance — of programs to be 
estimated by letting a performance model 
contain dependencies on the input data. 
More information on our performance an¬ 
alyzer can be found in the “Language 
support” section. 

Flexible performance models. The 

concepts of constraining performance 
characteristics on the one hand and deriv¬ 
ing expected performance characteristics 
on the other hand provide us with enough 
tools to implement basic real-time systems. 
However, they naturally give rise to the 
problem of how to deal with the situation 
where constraints cannot be met. 

One possibility is to use an exception 
mechanism that takes actions such as 
aborting low-priority tasks to provide more 
resources for high-priority ones. However, 
using the exception mechanism alone might 
not be appropriate for real-time software. 
Bihari 9 identifies some of the issues: 

• Real embedded systems have inertial 
properties that can smooth over temporary 
failures and overloads. Even deadlines that 
are asserted to be hard can occasionally be 
missed provided the system has the oppor¬ 
tunity to correct itself within a specified 
time period. 

• Time constraints themselves can be 
changed by the system. For instance, in a 
vehicle control system an appropriate ac¬ 
tion to overload is not “dump low-priority 
tasks” but rather “slow down and increase 
the distance to the vehicle in front.” A 
process control system might similarly re¬ 
lax its deadlines by decreasing gain in 
feedback-control loops. 

• Changes in the environment of a sys¬ 
tem might not only change the quantities 
with which the system works but require 
rapid, major changes in the control soft¬ 
ware, on the level of substituting entire 
algorithms. 

All of these issues suggest that software 
in real-time systems should have flexible 
structures. For example, computations in 
real-time systems can provide multiple al¬ 
gorithms and data structures, all of which 
perform the same function. Having a run¬ 
time system that can select from among 
these versions, based on the performance 
constraints, should be a major aid in per¬ 
forming these complex functions effec¬ 


tively. Flex has adopted such a model, 
called performance polymorphism, to ad¬ 
dress the use of different versions of an 
action in response to different performance 
criteria. This and the imprecise computa¬ 
tion model are discussed in the section 
entitled “Models of flexible real-time 
programs.” 

The Flex timing 
mechanism 

The Concord project at the University of 
Illinois involves building a programming 
environment for large real-time systems, 
supporting explicit timing constraints, im¬ 
precise computations, and multiple imple¬ 
mentations of a single computation. The 
goal is to support different configuration 
and timing constraints. This environment 
is built around the programming language 
Flex. 

Constraint blocks. The Flex program¬ 
mer describes time and resource require¬ 
ments by specifying constraints and prop¬ 
agating information among them. Rather 
than doing a general propagation scheme 
in which new information might be prop¬ 
agated through long chains of constraints. 
Flex uses a disciplined scheme where any 
change in execution state causes only those 
constraints immediately dependent on the 
change to be checked. No propagation of 
constraints is done. This discipline, which 
puts restrictions on the form of constraints, 
must be adopted to ensure that the execu¬ 
tion time of the constraint mechanism will 
be predictable. 

In Flex, constraints on time and resources 
are described by a new language construct, 
the constraint block. A constraint block 
identifies a constraint that must apply while 
a section of code is in execution and takes 
the form 

[label : ] (constraint; constraint; ...) 

[ -> {••.}] { 

... statements ... 

} 

This block specifies that the sequence of 
statements is to be executed and asserts 
that all of the constraints will be satisfied 
during the execution of the block. The 
optional label is provided so one constraint 
block can refer to another. The block of 
statements following the is optional and 
represents an exception procedure to be 
executed if any of the constraints fails. A 
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constraint might be either a Boolean ex¬ 
pression that is treated as an assertion to be 
kept throughout the block’s lifetime or a 
timing constraint that describes a constraint 
on the time when the block might begin or 
end its execution. 

An interval of time representing the 
lifetime of the block is associated with 
each constraint block. Another block might 
refer to the start ami finish times of a given 
block by using the block’s label. Thus, 
A.start represents the start time of block 
A, and A.finish represents the finish time 
of the block. As a convenience for the 
support of periodic and sporadic tasks, the 
boundaries of a constraint block might 
also be designated in terms of the relative 
time from the start of the block. B. duration 
represents the difference between the start 
and finish times of block B, and B. interval 
represents the difference between the start 
time of one execution and the start time of 
the next execution of the same block. Fig¬ 
ure 1 shows all four of these timing at¬ 
tributes. 

A timing constraint can take any of the 
forms shown in Table 1. The headings are 

Start or Finish time: Constraints can 
refer either to the time the computations 
represented by a constraint block begin or 
to the time that they complete. 

Absolute or Relative time: Absolute time 
iS'just what the name suggests and repre¬ 
sents the actual time of the start or finish 
event. Relative time represents the elapsed 
time from the start event to the event de¬ 
scribed. 

Earliest or Latest time: Constraints can 
refer either to the earliest time when an 
event might occur or to the latest time 
when it is permitted to occur. If a constraint 
refers to the earliest time and the flow of 
control reaches the beginning or end of the 
constraint block before the specified time, 
execution is delayed until the constraint is 
satisfied. If a constraint refers to the latest 
time and the flow of control reaches the 
beginning or end of the constraint block 
after the specified time, a timing fault oc¬ 
curs and execution is diverted to the recovery 
procedure (specified by the -* operator) or 
to a system fault handler. 

The left-hand side of a timing constraint 
is always a timing attribute of the block. 
The relational operator (> or <) can specify 
either the earliest or the latest time for the 
block. The right-hand side of a constraint 
can be a constant or an expression involving 
the program variables and/or the timing 
attributes of another constraint block. 


start finish 


Figure 1. Timing attributes of constraint blocks. 


Table 1. Timing constraints in Flex. 


Type of 

Absolute Time 

Relative Time 


Constraint 

Start Finish 

Start 

Finish 

Earliest 

start > t finish >t 

interval > t 

duration > t 

Latest 

start < t finish < t 

interval < t 

duration < t 


We can define a timing constraint rela¬ 
tive to the execution of another block. 
When one block refers to the attributes of 
another block that might be executed many 
times, the values always refer to the most 
recent activation of the block. 

The following are two examples that 
should help clarify the notation. 

Example 1: ( start > fi; finish < t 2 \ tem¬ 
perature < 110) 

This constraint specifies that the compu¬ 
tations must start at a time no earlier than 
and end at a time no later than t 2 . During the 
computations, the contents of the variable 
temperature must be less than 110 at all 
times. 

Example 2: A: (start > B.fmish) 

This constraint specifies that the computa¬ 
tion, identified as block A, cannot begin until 
another computation, identified as block 
B, has completed. 

Representing time. In Flex, we assume 
that time is represented as a sequence of 
discrete, quantized instants t 0 , fi, ... . An 
“event” is anything that can be identified 
with a specific instant. For Flex, the most 
significant events are the start and end of a 
computation. Instants are well ordered; for 
any two instants a and b, we assume that we 


know that a is earlier than, at the same time 
as, or later than b. In situations such as those 
that can arise in distributed systems, where 
events might actually occur simultaneously, 
we require that the systems have an unam¬ 
biguous way to determine an “earlier” or 
“later” relationship between events. On a 
single-processor system, two events might 
occur simultaneously if and only if they are 
the same event. While Flex does not specif¬ 
ically require that simultaneity be impossi¬ 
ble — since many parallel systems can easily 
support it — neither does it require that the 
underlying system support it. 

If an event has occurred in the past, we 
assume we know the precise time of its 
occurrence. Future events, however, are 
not known to the same degree of accuracy. 
We might know that an event is not al¬ 
lowed to occur until a certain time, or that 
it is not allowed to occur after a given time. 
We also always know that an event that has 
not occurred cannot occur before the cur- 

Flex represents the interval of time within 
which an event is known to take place as a 
time interval. A time interval comprises two 
times, the earliest and latest time when the 
event might occur. Thus, time intervals have 
the same structure as the familiar intervals of 
numerical analysis. A time interval repre¬ 
sents the range of uncertainty about when an 
event occurs. It does not represent the du¬ 
ration of a continued process. 
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Table 2. Samples of timing relations in Flex. 


Relation 

Implementation in Flex 

A = B 

A : (finish > B'.finish) { 

A': (start > B.start) { ... } 

} 


B : (finish > A’.finish) { 

B' : (start > A.start) { ... } 

} 

A meets B 

A : (finish > B.start) { 

A':(l){ ... ) 

} 


B : (start > A’finish) { ... } 

A starts B 

A:(l){ 

A': (start > B.start) { ... } 

} 


B : (finish > A.finish) { 

B' : (start > A.start) { ... } 

} 


Implementing and enforcing timing 
constraints. With the timing mecha¬ 
nisms provided in Flex, we can easily 
carry out many temporal relations. Allen 
presents a temporal logic based on intervals 
and defines 13 relations operating on 
pairs of intervals. 4 Figure 2 shows seven 
of the relations, and Table 2 shows the 


Flex code for three of them. The rest can 
also be easily carried out. In all cases, 
the “wait” and “synchronization point” 
(see the two sidebars) semantics are 
used, and no extraneous deadlines are 
introduced. The changes needed to de¬ 
fine deadline semantics are straightfor¬ 
ward. 


Next, we describe the complete struc¬ 
ture of a constraint block. The flow of 
control through the block is as follows: 

(1) A context for exception handling is 
established so the handler, if invoked, has 
the correct state to process. 

(2) The constraints that must be checked 
throughout the block’s execution are es¬ 
tablished. These are the nontemporal 
constraints and the constraints on earliest 
finish time (finish < t and duration < t). 

(3) Execution is delayed until the ear¬ 
liest start time is reached, fulfilling the 
start > t and interval > t constraints. This 
delay is performed under the control of 
additional timing constraints describing 
the latest start time ( start < t and interval 
< t). If these latter constraints are violat¬ 
ed, the block’s exception handler is in¬ 
voked. The structures describing the con¬ 
straints on the latest start time are then 
deleted, being deemed satisfied. 

(4) The block’s actual start time is re¬ 
corded. Its finish time is set to an un¬ 
known time. As a side effect of setting the 
start time, the interval (that is, the inter¬ 
arrival time of the block) is also set. 

(5) The user code for the body of the 
constraint block is executed. The non¬ 
temporal constraints and the constraints 
on latest finish time are still in effect. 

(6) The appropriate delays are made to 
satisfy constraints on the earliest possible 
finish time (finish > t and duration > t ). 

(7) The constraints on finish time and 
the nontemporal constraints are revoked. 

(8) Finally, the finish time of the block 
is recorded. As a side effect, the duration 
of the block is also set. 

Our current implementation on a Sun 
3/50 workstation takes roughly 9.5 mil¬ 
liseconds to enter a constraint block, 
establish a nontemporal constraint in¬ 
volving two variables, revert the con¬ 
straint, and exit the block. Nearly half of 
this time is spent on calls to the memory 
management routines. Specialized mem¬ 
ory management for the constraint data 
structures is expected to reduce this time 
substantially. 

Temporal constraints do not perform 
as well, needing about 15 milliseconds 
to enter a constraint block, establish a 
two-variable temporal constraint, revert 
the constraint, and leave the block. Vir¬ 
tually all the additional time is spent in 
Unix signal management routines. An 
implementation of our scheme using 
lightweight processes could no doubt do 
much better. 
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‘Fault’ versus ‘wait’ semantics 


The timing constraints in Flex come in two varieties: the “ear¬ 
liest time” and “latest time” constraints. If these are applied with 
dependencies among different blocks, there are two fundamen¬ 
tal ways of carrying out relations among the events. 

The first is what we call the “wait” semantics. Let us say that 
block A might not start until block B has finished. We might view 
this as a requirement to delay the execution of block A: 


A : (start > B.finish) {...} 


B:( 1) {...} 


Alternatively, we can adopt the “fault” semantics: We might 
view the constraint as a deadline on block B and require that B 
be completed before A starts, causing a timing fault if this con¬ 
straint is violated: 


A : ( 1 ) {...} 


B : (finish < A.start) { ...} 


Clearly these two constraints are synonymous in terms of 
the blocks’ temporal relationship, but there is a world of dif¬ 
ference in their behavior at runtime. 

As a matter of programming style, we prefer to impose as 
few arbitrary deadlines as possible on tasks. The former 
usage of causing a delay is preferred over the latter usage 
of imposing an additional deadline whenever possible. The 
range of applications where this will be possible will be ex¬ 
tended when a timing analyzer is added to Flex. 

The analyzer will make it possible to determine implicit 
deadlines on tasks for which the programmer has supplied 
no explicit deadline by determining the time required for the 
computations of succeeding tasks that are deadline driven. 


Equality between times 

Flex does not depend on the possibility of simultaneous 
events. Our interpretation of an equality constraint is that it rep¬ 
resents a synchronization point. When events A and B are con¬ 
strained to occur “at the same time,” the first to arrive must be 
delayed until the second arrives. 

The programmer describes such a constraint in Flex by the 
use of nested constraint blocks. Assume that operations A and 
B must begin at the same time. The Flex notation to express 
this relationship is 

A' (1) { 

A': (start > B.start) { 


} 

} 

e:(1){ 

S': (start> A.start) { 


} 

} 

Note that the constraints here are symmetrical; A bears the 
same relationship to B as B does to A. Let us examine what 
happens when we try to satisfy these constraints. Assume with¬ 
out loss of generality that the flow of control reaches A first. 

The constraint on block A is always satisfied, and so we try to 


enter block A'. The system finds that the current time is less 
than B.start (a future event is always known to occur after 
the current time), and therefore must delay execution until 
the flow of control reaches B. 

When control reaches B, the execution proceeds into 
block B, since S's constraint is always satisfied. Now, how¬ 
ever, B.start is known. This information propagates to the 
process waiting at block A', and this process is allowed to 
proceed, finding that the current time is now at least B.start. 
Meanwhile, the process in block B tries to enter block S' 
and finds that the current time is at least A.start. The entry 
to block B' therefore can proceed immediately. 

The naive implementation of synchronization points 

A: (start > B.start) { 


} 

S: (start > A.start) { 


} 

might be erroneous. This implementation results in dead¬ 
lock on any system incapable of supporting simultaneous 
actions. Each block will be waiting for the other to begin, 
and neither will begin until the wait is complete. 
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Models of flexible 
real-time programs 

The timing constraint block structure 
described above lets users define totally 
dynamic timing constraints. In addition, 
the runtime mechanism ensures that the 
timing constraints will always be followed, 
or else the block is aborted and the excep¬ 
tion handler is invoked. 

However, the constraint has solved only 
half of the problem for real-time computa¬ 
tions. It has attempted to ensure only the 
temporal correctness but not the functional 
correctness. It is still up to the programmer 
to carry out real-time programs that can 
provide an acceptable degree of functional 
correctness whenever the system must abort 
the computation to satisfy its temporal cor¬ 
rectness. 

We have identified two program models 
that can provide some functional correct¬ 
ness when the temporal correctness is en¬ 
forced under different system conditions. 
In this section, we describe the rationale 
behind these two models and their imple¬ 
mentations. 

Imprecise computations. In a real-time 
system, if a computation in progress has 
not completed when its deadline is reached, 
we have two alternatives: either we can 
discard the partial results from the com¬ 
putation, or we can try to use them in some 
fashion. If the partial results could consti¬ 
tute a useful approximation to the desired 
output, it is preferable not to discard them. 

We call this model of allowing incom¬ 
plete computations to produce approximate 
results imprecise computation. The notion 
of an imprecise result is a simple one, and 
adopting it for practical systems is easy. 
For example, many image processing sys¬ 
tems can produce fuzzy pictures even be¬ 
fore their operations are completely fin¬ 
ished. Many real-time applications use 
iterative numerical methods that can pro¬ 
duce early approximate results after enough, 
but not all, iterations are completed. 

To meet timing constraints in real-time 
programs, a computation must be able to 
behave gracefully whenever it is aborted 
prematurely. Whenever possible, we sug¬ 
gest that real-time programs be carried out 
as imprecise computations so they can 
produce acceptable results given any rea¬ 
sonable amount of time. 

Programs can be carried out as iterative 
processes that produce more refined results 
as more time is permitted, or they can use 
the divide-and-conquer strategy that pro¬ 


vides partial results along the way. Other 
approaches are also possible to return par¬ 
tial, early, or imprecise results. 

To invoke an imprecise computation, a 
program might call the computation using 
the impcall command instead of the normal 
procedure call. There are two timing models 
of impcall commands. In the synchronous 
model, the timing constraint for the com¬ 
putation is defined at the time of the in¬ 
vocation; in the asynchronous model, the 
timing constraint is not known until after 
the computation is started. In either case, 
the imprecise computation then starts its 
computation using the parameter values 
passed from the caller program. 

From time to time, the computation will 
make imprecise results available by using 
the impreturn command. The computation 
is terminated when the deadline is reached 
or the computation has completed. 

Once the program for an imprecise 
computation is constructed, we can define 
its performance capacity in a reward 
function by running test data and monitor¬ 
ing the resultant qualities along the time 
line. Given the reward function, we can 
decide how much time should be given to 
a computation to receive a result of ac¬ 
ceptable quality for a given application. 
Much research has been done on the var¬ 
ious issues on imprecise computation. We 
refer interested readers to another article, 
by Liu et al., 10 in this issue (pp. 58-68). 

Performance polymorphism. Another 
approach to addressing the need for multi¬ 
ple program performances is to carry out 
multiple versions of a function that carries 
out a given computation. These versions 
all perform the same task and differ only in 
the amount of time and resources they 
consume, the system configuration to which 
they are adapted, the precision of the re¬ 
sults that they return, and similar perfor¬ 
mance criteria. 

The versions might be specialized for a 
particular machine architecture, a particu¬ 
lar problem size, a particular optimization 
strategy, and so on. The multiple versions 
might be supplied by the programmer, as 
when different algorithms adapted to prob¬ 
lems of different sizes are supplied. They 
might also be generated automatically, as 
when a program rewriting tool adapts a 
sequential program to a vector or parallel 
machine. 

For real-time programs, we present a 
model for specifying these multiple ver¬ 
sions. We call this model performance 
polymorphism because of its similarities to 
the conventional polymorphism where dif¬ 


ferent functions carry out the same opera¬ 
tion on different types of data. 11 

The example we use is that of sorting on 
a parallel computer system. We have (at 
least) three different sorting techniques 
available: a fast insertion sort isort, a heap 
sort hsort, and a parallel merge sort bsort. The 
amount of time that these sorts take is An 2 + 
Bn + C, Dn log n + E, and F(n log n)/p + G 
log p + H, respectively, where n is the 
number of elements to sort and p is the 
number of processing elements given to the 
parallel sort. We expect H, the overhead of 
starting the parallel sort, to be quite large. 
Therefore, it might, be more effective to sort 
a short list of numbers on the local proces¬ 
sor. We also expect the constant factor in 
the time required for heap sort to be greater 
than that for insertion sort. Therefore, 
choosing the 0(n 2 ) insertion sort for ex¬ 
tremely short lists might be more effective. 

Language support. To carry out the model 
of performance polymorphism, we augment 
Flex with a means to describe the candidates, 
their performance, and the goals. In this 
section, we use simple examples to show 
the various primitives. 

We begin by providing a means to de¬ 
clare a performance polymorphic func¬ 
tion, by letting the keyword “perf_poly” 
replace the function body in a function 
declaration. 

Example 3: void sort (int n, int* list) 
perf_poly; 

This example declares sort to be a perfor¬ 
mance polymorphic function accepting an 
integer n and a “pointer to integer” list. 
Presumably, sort is a function that sorts a 
list of integers. 

Next, we provide a way to give a candidate 
for a performance polymorphic function. 
We do this by adding an external definition 
to the language: 

Example 4: provide hsort for void sort 
(int, int*); 

This example supplies the function hsort as 
a candidate for the sort function defined 
above. The description of the types accept¬ 
ed and returned by the sort function must be 
supplied because sort might be polymor¬ 
phic in the conventional sense as well. 
There might, for instance, be another sort 
function that sorts a list of floating-point 
numbers. 

Finally, we need to add a description of 
the goal. We do this by extending the def¬ 
inition of a compound statement: 
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Figure 3. A programming environment for performance polymorphism. 


Example 5: #pragma objective minimize 
duration 

The directive shown in this example requests 
that the system minimize the real time taken 
to perform the computations enclosed in the 
braces, subject to all constraints. 

The only other data needed to perform the 
binding step are the claims that describe the 
resource requirements for the candidates. 
We have carried out a program timing tool 12 
that can measure the time required for a 
computation under various conditions and 
integrate these measured times into a para¬ 
metric model supplied by the programmer. 
Novel features in our tool include the ca¬ 
pacity to 

• analyze program structures that are 
difficult for other systems, such as 
unbounded loops and recursive con¬ 
trol structures; 

• provide accurate timing information 
even on hardware whose timing be¬ 
havior is difficult to model and ana¬ 
lyze; and 

• provide confidence in the timing 
model, by validating it statistically 
for goodness of fit. 

To support timing measurement and 
modeling. Flex is augmented with a mea¬ 
surement directive, “#pragma measure.” 
This directive both instructs the compiler 
to generate code to measure the time or 
resources consumed by a block of code and 
provides the parametric model for analyzing 
the measurement. Next, we show an exam¬ 
ple of the pragma directive. 

Example 6: #pragma measure mean du¬ 
ration defining A, B, C in (A * n + B) * n + 
C safety 2 

The pragma informs the timing tool that 
the mean duration (average time) taken by 
the computation is expected to be a quadratic 
function of the input variable n. Once the 
program has been compiled and run, possi¬ 
bly a number of times to collect the mea¬ 
surement data, the analysis tool is run. 

This tool determines the best fit of the 
parameters to the observed runtime. It pro¬ 
duces the values of the parameters A, B, and 
C, and also reports the confidence level (us¬ 
ing the X 2 statistic) for the analysis. In this 
example, the programmer has also specified 
that a safety factor of two is to be provided. 
This safety factor reflects the programmer’s 
knowledge that the algorithm used, in the 
worst case, requires twice the amount of time 
that it does on average. 


Binding issues. Given all the information 
described above, late binding at runtime is 
easy to describe. This algorithm simply 
loops through all the candidates, looking for 
feasibility, and selects the candidate with the 
greatest figure of merit. This is obviously 
somewhat expensive (the computation of the 
resource claims is a loop that is nested within 
the loop through the candidates). However, 
assuming that a few configurations of the 
parameters account for most of the invoca¬ 
tions, we can improve the binding overhead 
by caching the resource claims and feasibil¬ 
ity information. 

The caching records the configuration of 
the parameters for the last few calls to the 
function and, as the first part of the binding 
step, checks whether the parameters sup¬ 
plied match a recent invocation. If so, the 
binding need not be recomputed; the system 
can simply reuse the binding that was used 
on the earlier invocation. 

The advantage of runtime binding is its 
flexibility. It is required for cases where the 
relevant parameters cannot be determined at 
compile time. Such cases include data- 


dependent performance, where input data 
obtained at runtime can affect the binding 
decision; fault-tolerant systems, where run¬ 
time binding might be needed to reconfigure 
around a system failure; and runtime alloca¬ 
tion of time and resources. 

The disadvantage of runtime binding is 
the overhead involved in making the binding 
decision; therefore, we prefer early binding 
in the cases that do not require late binding. 
We also recommend appropriate choice of 
granularity for performance polymorphic 
functions that will require late binding. Short 
functions that complete in only a few instruc¬ 
tion times are not appropriate candidates 
because the cost of choosing an inappropri¬ 
ate function is small compared to the cost of 
binding. 

A programming environment. A pro¬ 
gramming environment that supports perfor¬ 
mance polymorphism is being implemented. 
It provides the programmer the tools to spec¬ 
ify and conduct the performance measure¬ 
ments and to decide the binding time. Figure 
3 shows the overall structure of our system. 
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In the figure, boxes are tools implement¬ 
ed, and rounded boxes are program and 
data files used as inputs or produced as 
outputs by the tools. The left subsystem 
has all the compilers. Flex programs are 
processed by the Flex compiler. 

The output of the Flex compiler is a C++ 
program that is, in turn, processed by a 
C++ compiler to produce an object program. 
The object program contains the guarded 
commands needed to invoke performance 
polymorphic functions. It also contains the 
codes to measure the execution time and 
resource commitment required for the var¬ 
ious versions of the performance polymor¬ 
phic functions. 

The lower right subsystem in the figure 
is the dynamic timing analyzer. It starts 
with the dynamic timing model that is 
produced by the Flex compiler from 
“#pragma measure” directives supplied by 
the programmer. The model describes a 
parametric function whose parameters are 
to be determined by the actual timing data 
obtained by running the program. 

Determining these parameters is the role 
of the dynamic timing analyzer. It reads the 
model description and the actual time and 
resource measurement data obtained by 
running the program. It writes a file con¬ 
taining the parameters of the model. Sub¬ 
sequent runs of the Flex program might use 
these parameter values to estimate the run¬ 
ning times of performance polymorphic 
function versions in making binding deci- 

The static timing analyzer at the upper 
right in Figure 3 is a planned future sub¬ 
system. Its role is to determine the times 
and resource commitments required for 
high-level constructs. It can determine these 
times based on the measured times, exam¬ 
ination of the object code, the constraint 
structure of the program, or any combina¬ 
tion of these. The static analyzer will be 
capable of generating a description of the 
performance of the versions of a function. 
The description can be used in a subse¬ 
quent compilation to optimize for early 
binding. 


M any real-time-system environ¬ 
ments are dynamic. They are 
subject to different work loads, 
unexpected failures, and dynamic time 
constraints. Real-time systems that are to 
perform in such environments need to be 
able to handle such variations. Currently, 
the environmental problems are handled 
by using low-level operating system prim¬ 
itives that are neither flexible nor portable. 


The timing constraint primitives in the 
Flex programming language are easy to 
use yet powerful enough to define both 
independent and relative timing constraints. 
Program models like imprecise computa¬ 
tion and performance polymorphism can 
carry out flexible real-time programs. In 
addition, programmers can use a perfor¬ 
mance measurement tool that produces 
statistically correct timing models to pre¬ 
dict the expected execution time of a pro¬ 
gram and to help make binding decisions. 

Using our approach, the burden of meet¬ 
ing all deadlines is partly shifted from the 
programmer to the runtime system. Of 
course, the programmer still has to carry 
out programs that can produce results with 
adequate precision, given a reasonable 
amount of time. In this way, the flexibility 
needed for dynamic real-time systems can 
be achieved. ■ 
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STANDARDS 


Editor: Fletcher J. Buckley, 103 Wexford Dr., Cherry Hill, NJ 08003, telephone (609) 866-6350, fax (609) 866-7753, Compmail II f.buckley@compmail.c 



Point/Counterpoint 


Questions on ethical standards 


In the February 1991 issue of Computer, this department carried its second article 
about ethical standards by Michael C. McFarland, a Jesuit priest. Previously, McFar¬ 
land had authored an essay entitled “Urgency of Ethical Standards Intensifies in Com¬ 
puter Community”; it appeared in the March 1990 issue. His 1991 followup was entitled 
“Ethics and the Safety of Computer Systems. ” 

Below, Richard Plourde, a system-design consultant, takes issue with several points 
made in the February 1991 article. McFarland’s counterpoints follow. — Editor 



Richard Plourde 

I would like to respond to Michael C. 
McFarland’s article in the February 1991 
issue of Computer , pp. 72-75.1 acknowl¬ 
edge my lack of authority in the study of 
ethics. However, as a human being who 
thinks of himself as ethical, I feel more 
than a little uncomfortable with several of 
McFarland’s premises. Perhaps discom¬ 
fort is an intrinsic part of ethical issues. 

The premise of absolutism. Part of 
my discomfort was created by the suc¬ 
cinct codification of the ethical issues 
addressed. The issues were not hand- 
waved aside with noble bromides; they 
were faced head-on, with clarity and or¬ 
ganization. That clarity encouraged 
thought, and further discomfort, particu¬ 
larly with two of the article’s premises 
and the resultant path of its comments. 

The first premise is absolutism. Under 
the heading “Proportionality,” McFar¬ 
land wrote: “There must be no alterna¬ 
tive that achieves the same or compara¬ 
ble benefits with less harm or risk.” 

Then, a few paragraphs later, he said, 
“Getting the best possible estimate of the 
effects of technology, economically, in 
terms of lives saved, and so on, is impor¬ 
tant” and “Determining the risks as pre¬ 
cisely as possible is also important.” 

The hazards of absolutism. The con¬ 
cepts of “no alternative” and “as possi¬ 
ble” are absolutes. Compliance with ab¬ 
solute criteria implies omniscience. Until 


such time as everything is known, the 
possibility of knowing more exists. Eval¬ 
uating “risks as precisely as possible” 
implies an exhaustive search of all litera¬ 
ture and the performance of all imagin¬ 
able experiments to establish risk. Until 
no more information can be gathered, the 
constraint is not met. 

The knowledge that there is no better 
alternative requires knowledge of the 
ramifications of all alternatives. The task 
of meeting that requirement is sufficient 
to halt any product development; in a li¬ 
tigious society such as ours, the unchal¬ 
lenged statement of such an absolute in a 
credible forum is, at the very least, haz¬ 
ardous. 

My concern is paradoxically addressed 
in the body of the article by such state¬ 
ments as, “The problem is how to priori¬ 
tize them. In other words, how do you 
formulate and apply norms in situations 
where these principles come into con¬ 
flict?” 

The issue of semantics is important. 

We read articles such as McFarland’s for 
a number of reasons, including 

• legal guidance — an identification of 
our obligations in the eyes of others; 

• moral guidance — the things we 
should be concerned about in our 
quest to become more decent per¬ 
sons; and 

• philosophical curiosity — an awaken¬ 
ing to the art and beauty of thinking. 

The implied prerequisite of omniscience 
places a seriously intimidating burden on 
the very persons most likely to be influ¬ 
enced by an article on ethics. 

The premise of altruism. Another 
premise that troubled me is not unique to 
this article. It is common in discussions 


about ethics. The premise is the one un¬ 
derlying the “public welfare” segment of 
the section “The ethics of virtue.” 

The premise is that choosing to aid the 
public welfare leads to a path that will, in 
fact, aid the public welfare. This premise 
has seldom been tested, although there is 
a good deal of evidence that might be ap¬ 
plied to an analysis. 

As I consider the little I know of histo¬ 
ry, I find examples where altruistic be¬ 
havior has benefited society and others 
where it has harmed society; I find exam¬ 
ples where profit-driven behavior has 
benefited society and others where it has 
harmed society. 

I haven’t done a balanced study, but it 
does seem that profit-driven behavior has 
been, in the long term, more beneficial 
and less harmful than altruistic behavior. 

The use of the market. McFarland 
writes: “Of course, the market is sup¬ 
posed to mediate the wishes of the pub¬ 
lic, but it is an imperfect medium at best. 
In particular, it often does not adequately 
reflect the hidden risks of a technology, 
at least not until it is too late. Serving the 
market is not the same as serving the 
safety, health, and welfare of the public.” 

It is not clear that any other factor has 
a higher correlation with “safety, health, 
and welfare of the public” than the mar¬ 
ket-determined choices of the public it¬ 
self. 

I am not arguing for 

(1) A “the public be damned” attitude. 
Such an attitude is often self-destructive, 
even when ethics are not the issue. (For 
example, a good argument could be made 
in support of “whistle blowing” as an aid 
to corporate development and profits.) 

(2) Shoddy work or the creation of 
products that fail or mislead customers, 
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or the creation of products that the re¬ 
sponsible person believes are generally 
destructive to society. 

I am arguing for caution in the zealous 
application of ethical standards, for I see 
some destructive potential in that appli¬ 
cation. 

The ethical requirement for omni¬ 
science leaves people with two choices: 
doing nothing (which is ethically neutral) 
or becoming omniscient. Of course, peo¬ 
ple can’t become omniscient; they can 
only pretend omniscience or convince 
themselves of their omniscience. Both 
practices constitute falsification of data. 

If I “must do only good and do no 
harm,” then I must be either very lucky 
or accept the possibility of being ethical¬ 
ly corrupt. If I cannot accept the possibil¬ 
ity of being ethically corrupt, then I must 
prevent any awareness of my having 
done harm. This strikes me as a sure path 
to the very ethical corruption I am trying 
to avoid. 

The physician’s example revisited. 

I’m inclined to use the same example as 
did McFarland: the physician. “It is in¬ 
structive to compare the sense of duty of 
computer professionals with that of phy¬ 
sicians. The physician’s primary obliga¬ 
tion is to the patient. Despite any short¬ 
comings that might exist, that obligation 
is taken seriously in the medical profes¬ 
sion,” McFarland wrote. 

It is also instructive to compare the 
benefits provided to society and the costs 
of those benefits. 

If duration or longevity is the only 
measure of value, physicians certainly 
add more value than computer profes¬ 
sionals. (Of course, if duration is the 
only measure of value, freedom has no 
value over imprisonment.) 

If, on the other hand, lifetime value is 
the integral of quality over time and lis¬ 
tening to Beethoven is considered a high¬ 
er quality event than writing numbers in 
a ledger book, the function becomes 
much more complicated. If quality inte¬ 
grated over time and the number of per¬ 
sons affected is a measure of goodness, I 
think the technologist has little to be 
ashamed of. 

The technologist does not expect per¬ 
fection in his work; the technologist can 
be wrong. We have given only lip ser¬ 
vice to the “higher” constraints of ethics 
(being content, generally, to do a good 
job and to serve the needs of our own 
consciences). 

The physician has given preeminent 
concern to ethics. I wonder if that con¬ 
cern is not a factor in the explosion of 
health-care costs, the slowness of 
progress in medical research, and the 
perception by so many that doctors are 


The argument seems to fall 
into the category of an 
idealist versus a 
pragmatist, but this 
comparison is faulty. An 
ideal is...an evaluable model 
of a complex process. 


“arrogant,” “indifferent to patients as 
people,” and “convinced they are gods.” 

High correlations do not define causal¬ 
ity, but when they violate our precon¬ 
ceived notions (or perceptions) of how 
things “ought” to be, they do encourage 
investigation. 

The ideal as a model. The argument 
seems to fall into the category of an ide¬ 
alist (McFarland) versus a pragmatist 
(me), but this comparison is faulty. An 
ideal is a special kind of idea. I think of 
an ideal as an evaluable model of a com¬ 
plex process. 

An ideal must relate to reality. Ideas 
may exist outside the context of reality — 
“pure” mathematics falls into this category 
— but then, the idea is complete in itself 
and requires no equivalent entity or ideal. 

The perfection of an ideal is a conse¬ 
quence of its simplicity. But, would the 
earth be any better if it met that ideal? 
(For one thing, it would be covered with 
water, and we’d probably all be fish.) 

The quality of the ideal is the measure 
of how well it predicts real behavior in a 
particular case. At times, we work from 
an ideal to create a new reality. 

A good example is the creation of ball¬ 
bearings for low-friction moving systems. 
In this case, we design a system to use an 
“ideal” bearing, of 1-millimeter diameter, 
and make the bearings as close as we can 
to that ideal. When we do this, we must 
establish that we really want a 1-millime¬ 
ter bearing, not a 1.1-millimeter bearing. 
If we’re wrong, the quality of the bearing 
is irrelevant because the system doesn’t 
work. Even then, it is extremely risky to 
define an ideal bearing with a yield 
strength unavailable in real materials. 

Once again, the quality of the ideal de¬ 
pends on the degree to which it repre¬ 
sents reality. 

The inadequacy of the ideal as a 
model. I suspect that the model of the 
human technologist and of our society, 
the ideal, used to develop the ethic pre¬ 
sented in the article is inadequate for the 
prediction of results. 

McFarland, under the heading “Risk 


analysis,” recommends that we should 
have “...testing requirements that, given 
certain program characteristics, the envi¬ 
ronment, and the acceptable level of risk, 
tell how much and what type of testing 
should be done.” If we were to use that 
advice as an ethical prerequisite, would 
we end up with more robust, effective, 
more useful programs, or would we 
merely stagnate development by making 
excursions into new areas ethically im¬ 
possible? 

If, somehow, we were all to adopt a par¬ 
ticular ethic (presumably an altruistic eth¬ 
ic) and live up to that ethic, would things 
be better overall than they are now? 

Is there an ethic that would meet its 
own tests? 


Counter¬ 

point 


Michael C. McFarland 
Boston College 


Richard Plourde, in his thoughtful 
commentary, has raised an important 
point about the application of ethical cri¬ 
teria in real situations. The norms I pro¬ 
posed for the evaluation of new technol¬ 
ogy are not like a computer program. 
They are not a set of rules that can be ap¬ 
plied mechanically to a well-defined 
body of data to produce results with 100- 
percent reliability. 

Ethical decisions require human judg¬ 
ment — the exercise of what Aristotle 
called phronesis or practical wisdom. We 
must draw on our awareness of the par¬ 
ticulars of a situation, including the 
present facts and past history, our sensi¬ 
tivity to the values and principles in¬ 
volved, our foresight of the possible con¬ 
sequences of different courses of action, 
and our ability to deliberate and weigh 
competing values. And we must do this 
knowing that we might be wrong. 

No amount of ethical analysis can pro¬ 
tect us from the awful responsibility we 
must accept for our judgments, or from 
the risk of failure. 

Does that mean ethical norms are use¬ 
less? I think not. They can still provide 
valuable guidance in our deliberations. 
For example, we can never be certain 
that we have considered all alternatives 
to a risk-prone technology, as Plourde 
points out. Nevertheless, we can and 
should make a good-faith effort to find 
alternatives that are less risky. 
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Simi!;n i\, while we can never be cer¬ 
tain tha. we have foreseen all the conse¬ 
quences of a new technology, we do have 
well-developed analytical methods that 
we can use, along with experience and 
common sense, to anticipate those conse¬ 
quences. 

If we do not have the analytical frame¬ 
work or the experience to predict the 
consequences with a reasonable degree 
of assurance, as with some types of soft¬ 
ware, that is in itself an indication that 
we should be very conservative in our 
use of the technology. 

So, the norms are important because 
they tell us what questions to ask. But 
how do we know when to be satisfied 
with the answers? We do not expect per¬ 
fection, but we do expect a good-faith ef¬ 
fort to make the best possible judgment 
in a given situation. For example, did the 
person making the judgment pay atten¬ 
tion to the relevant ethical norms? Did he 
or she follow good engineering practice 
and make best use of all available re¬ 
sources, including the knowledge and ex¬ 
perience of others, the standard literature 
on the subject, and the best analytical 
techniques? Was the decision a reason- 


There is no avoiding the 
responsibility to make the 
best possible judgments on 
the use of technology. That 
means making reasonable 
judgments based on 
knowledge, analysis, 
experience, and sound 
principles, ethical as well 
as engineering. 


able one given what was known or could 
be deduced on the subject? 

These are tough questions, but they’re 
not impossible to answer. Engineers face 
them all the time and do a pretty good 
job with them. 

Plourde has done us a service by 
pointing out the hazards of applying ethi¬ 
cal norms in practice. I think most of us 
have felt some of the same doubts. But I 


do not share his cynicism about the value 
of altruistic behavior. 

It is true that ethical principles and 
norms cannot guarantee perfection. Nev¬ 
ertheless, that is no justification for giv¬ 
ing up trying to do what is right. 

There is no avoiding the responsibility 
to make the best possible judgments on 
the use of technology. That means mak¬ 
ing reasonable judgments based on 
knowledge, analysis, experience, and 
sound principles, ethical as well as engi¬ 
neering. 

While it may sometimes happen that 
even the best, most altruistic judgments 
go wrong, much more often we fail 
through ignorance, prejudice, selfishness, 
or sloth. Moreover, even if a good deci¬ 
sion does lead to an undesirable out¬ 
come, that does not mean that the effort 
has been wasted. Virtue is valuable in it¬ 
self and a source of happiness. It needs 
no other justification. 

We all strive to be good, in our jobs as 
well as in the rest of our lives. For those 
of us who are computer professionals, 
that means our judgments should no only 
be technically sound, but should uphold 
the common good. 
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6TH WORKSHOP ON 
PARALLEL AND 
DISTRIBUTED SIMULATION 
(PADS) 

Jointly Sponsored by 
SCS, IEEE, and ACM 
20-22 January 1992 
(part of the 1992 Western Multiconference) 
Newport Beach, California 


Topics of interest include: 

Methods for concurrent simulation: (e.g., discrete, continuous, 
combined, real time, optimistic, conservative) 

• Architecture and language support for concurrent simulation 

• Performance evaluation of concurrent simulation methods 

• Special purpose parallel simulations (e.g., logic, cache simulations) 

• Industrial applications of concurrent simulation 

Exceptional papers will be forwarded to the ACM Transactions on 
Modeling and Computer Simulation. Proceedings are published in 
hardbound form by The Society for Computer Simulation. 

DUE DATES: Six copies of submissions 1 July 1991 

Notification of acceptance 15 September 1991 
Camera-ready copy due 15 October 1991 

Submit papers to Marc Abrams, Program Chairman, Department of 
Computer Science, Virginia Tech, Blacksburg, VA 24061-0106, e-mail 
abrams@cs.vt.edu, (703) 231-8457, fax (703) 231-6075. 

For further information, contact Paul Reynolds, General Chairman, 
Dept of Computer Science, Olsson Hall, University of Virginia, 
Charlottesville, VA 22903, e-mail pfr@louisxiv.ipc.virginia.edu, (804) 
924-1039. 
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Editor: Guylaine M. Pollock, Sandia National Laboratories, Division 1424, PO Box 5800, Albuquerque, NM 87185; phone, (505) 846-0040; Internet, gmpollo@cs.sandia.gov 


Board of Governors adopts budget targets for 1992 

Guylaine Pollock, Computer Society News editor 


As the first step in the new budget de¬ 
velopment process adopted last fall, the 
IEEE Computer Society Board of Gover¬ 
nors, at its March 1 meeting at Compcon 
Spring 91 in San Francisco, approved a 
set of preliminary budgetary targets for 
each major program area. The net of all 
the individual targets is to produce a 
minimal budgeted surplus of $750,000 in 
1992. The $750,000 annual goal was set 
by the board in June 1990 to rebuild the 
society’s depleted reserves. 

Now the individual program boards 
will try to develop budgets that meet the 
overall target assigned to each. “Al¬ 
though the ultimate responsibility and 
authority to pass the budget remains with 
the Board of Governors, the attempt is to 
move the effective decision-making lo¬ 
cus as low as reasonable in the organiza¬ 
tion,” explained society President Dun¬ 
can H. Lawrie. “In this way we hope to 
keep the programs reflected in the budget 
as closely tied to the needs and desires of 
the membership as possible,” he added. 

Bylaws amendment. The Board of 
Governors also approved, for the second 
time, an amendment to the bylaws, Arti¬ 
cle XIII, Section 9. The amendment con¬ 
cerns the inclusion of the president-elect 
as a member of the Nominations Com¬ 
mittee and the resolution of the ambigu¬ 
ity introduced (item 5) by a recent bylaw 
change making vice presidents ex officio 
members of the board. The proposed 
amendment was approved for the first 
time at the November 16, 1990, board 
meeting and was subsequently published 
in Computer (January 1991, p. 94) for 
comments from the membership. 

The new bylaw reads as follows, with 
the new additions shown in italics: 

Section 9: Nominations Committee 

The Nominations Committee shall 
consist of: 

(1) the past president as committee 
chairperson; 

(2) the president-elect or his/her des¬ 
ignee; 


(3) one member appointed by the past 
president; 

(4) one franchised member of the 
Board of Governors appointed by 
the president; 

(5) one society member, not a voting 
member of the Board of Gover¬ 
nors, appointed by the president; 
and 

(6) one franchised member of the 
Board of Governors elected by the 
immediately previous Board of 
Governors. 

Additional actions. In other actions, 
the board elected Akihiko Yamada, 
Tadao Ichikawa, Yale N. Patt, Thomas 
W. Williams, and Ronald Waxman to 
the Audit Committee as forwarded on 
behalf of the Nominations Committee 
by Helen M. Wood, Nominations Com¬ 
mittee chair. 

Upon the recommendation of the soci¬ 
ety’s Publications Board, the Board of 
Governors unanimously adopted a reso¬ 
lution instructing the society president to 
inform the IEEE Signal Processing Soci¬ 
ety, IEEE TABS, and the IEEE Publica¬ 
tions Board that the Computer Society 
opposes the creation of a proposed new 
journal, IEEE Transactions on Image 
Processing. This opposition is based on 
the apparent high degree of overlap with 
the society’s existing successful journal, 


1990 Gordon Bell prizes 

Winners of the 1990 Gordon Bell 
Prize, which recognizes significant 
achievements in the application of su¬ 
percomputers to scientific and engineer¬ 
ing problems, were announced February 
27 at Compcon Spring 91 in San Fran¬ 
cisco. 

In the category of price/performance, 
the winners are G. A1 Geist and G. Mal¬ 
colm Stocks of the Oak Ridge National 
Laboratory, Beniamino Ginatempo of the 
University of Messina, Italy, and Willi¬ 
am A. Shelton of the US Naval Research 


IEEE Transactions on Pattern Analysis 
and Machine Intelligence. 

The board passed a motion to discon¬ 
tinue the Technical Committee on Com¬ 
puter and Display Ergonomics because 
of inactivity and lack of member interest, 
as recommended by the Technical Activ¬ 
ities Board and presented by Mario R. 
Barbacci, vice president for Technical 
Activities. Also, the board approved a 
name change for the Technical Commit¬ 
tee on Computing and the Handicapped, 
which officially becomes the Technical 
Committee on Computing and Persons 
with Disabilities. Barbacci reported the 
initiation of two new task forces within 
TAB: the Task Force on Parallel Pro¬ 
cessing and the Task Force on Computer- 
Based Systems Engineering. 

In addition, the board passed a motion 
proposed by Helen M. Wood directing 
the Membership Activities Board to de¬ 
velop a comprehensive program for stu¬ 
dent members and to consider how IEEE 
Potentials could best be used in such a 
program. 

The board endorsed the decision of 
1991 President Duncan H. Lawrie, 1990 
President Helen M. Wood, and 1992 
President Bruce D. Shriver for the Com¬ 
puter Society to assume ownership and 
responsibility for publishing the Annals 
of the History of Computing. AFIPS, the 
previous publisher, has been dissolved. 


awarded 

Laboratory. The team computed the elec¬ 
tronic structure of a high-temperature su¬ 
perconductor on a 128-node Intel iPSC/ 
860 at a price/performance rate of 840 
megaflops per million dollars. They also 
solved the same problem on a network of 
10 IBM RS/6000 workstations at a rate 
of 1.3 gigaflops per million dollars. 

Gary Sabot, Lisa Tennies, and Alex 
Vasilevsky of Thinking Machines and 
Richard Shapiro of United Technologies 
are the winners in the compiler parallel¬ 
ization category. They used a Fortran-77- 


May 1991 


83 




to-Fortran-90 conversion package to par¬ 
allelize a grid-generation program used 
to solve partial differential equations. 
They achieved a speedup of more than 
1,800 and ran at over 1.5 gigaflops on a 
Connection Machine with 2,048 floating¬ 
point processors. 

Two honorable-mention prizes were 
also awarded. Last year’s winners in the 
raw-performance category submitted the 
same application, but they increased the 
size of the original problem while im¬ 


proving their performance two and half 
times — to 14 gigaflops — by modifying 
only the compiler and library. Team 
members were Mark Bromley, Steven 
Heller, Cliff Lasser, Bob Lordi, Tim Mc- 
Nerney, Jacek Myczkowski, Irshad Muf¬ 
ti, Guy L. Steele, Jr., and Alex Vasi¬ 
levsky, all of Thinking Machines. 

The other honorable mention went to 
Eran Gabber, Amir Averbuch, and 
Amiram Yehudai of Tel Aviv University 
for a parallelizing Pascal compiler. They 


successfully parallelized 14 programs, 
including one of the programs that won 
the first Gordon Bell Prize, achieving 
speedups of almost 25 on 25 processors 
of a Sequent Symmetry. 

The judges for this year’s Gordon Bell 
Prize were Alan Karp of IBM’s Palo 
Alto Scientific Center, Jack Dongarra of 
the Oak Ridge National Laboratory, Ken 
Miura of Fujitsu America, and Horst Si¬ 
mon of the NASA Ames Research Center 
and Computer Sciences Corp. 


IEEE and Computer Society present awards at Compcon 


The IEEE presented three major 
awards for 1991, and the IEEE Computer 
Society recognized recipients of service 
awards during ceremonies at Compcon 
Spring 91 on February 27. 


Kobayashi Award. The 1991 IEEE 
Koji Kobayashi Computers and Commu¬ 
nications Award was presented to Ste¬ 
phen S. Lavenberg and Martin Reiser for 
“fundamental contributions to the theory 


and practice of computer and communi¬ 
cations systems performance modeling.” 
The award recognizes their invention of 
mean value analysis, which provides a 
set of recursive equations relating the 
principle performance measures of inter¬ 
est, mean queue lengths, mean waiting 
times, and throughputs, in a class of per¬ 
formance models called product-form 
queueing networks. 

The MVA equations have been widely 
implemented in performance modeling 
software and are a basic part of perfor¬ 
mance modeling courses. They have re¬ 
sulted in a large body of research in de¬ 
veloping MVA-like approximations for 
other types of performance models. 

Lavenberg is senior manager of the 
Systems Analysis Department at the IBM 
T.J. Watson Research Center in Yorktown 
Heights, New York. Reiser, while pursu¬ 
ing individual projects, advises IBM on 
matters of communication strategy. 

Piore Award. The IEEE Emanuel R. 
Piore Award is given for outstanding 
achievement in the field of information 
processing in relation to computer sci¬ 
ence. This year’s winner is Joseph F. 
Traub, chairman of the Computer Sci¬ 
ence and Telecommunications Board of 
the National Research Council. 

Traub was recognized for “pioneering 
research on algorithms and computation¬ 
al complexity, parallelism, optimal itera¬ 
tion theory, and for leadership in com¬ 
puting education.” He began 
investigating the complexity of iterative 
processes in 1959 and went on to study 
globally convergent methods for polyno¬ 
mial zeros, parallel algorithms, and par¬ 
allel computational complexity. 

Formerly head of the Computer Sci¬ 
ence Department at both Carnegie Mel¬ 
lon and Columbia Universities, Traub is 
the author or editor of eight books and 
the founding editor of the Journal of 
Complexity. 



Above: IEEE President-elect Merrill W. Buckley, Jr., (left) presents the 1991 
IEEE Koji Kobayashi Computers and Communications Award to co-winner 
Martin Reiser. Below (left to right): Stephen S. Lavenberg, who shared the 
Kobayashi Award with Reiser; Joseph F. Traub, winner of the 1991 IEEE Eman¬ 
uel R. Piore Award; and Fletcher J. Buckley, recipient of the 1991 IEEE Charles 
Proteus Steinmetz Award. 
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Steinmetz Award. The 1991 IEEE 
Charles Proteus Steinmetz Award went 
to Fletcher J. Buckley, a software engi¬ 
neering manager at General Electric, for 
“contributions to IEEE computer soft¬ 
ware standards activities.” A founding 
member of the Computer Society’s Soft¬ 
ware Engineering Standards Committee, 
Buckley served as the society’s first vice 
president for Standards. As an active 
member of the IEEE Standards Board, he 
was instrumental in initiating the drive 
toward transnationalization of IEEE stan¬ 
dards. 

Buckley is the Standards editor for 
Computer and past chair of the IEEE 
PI209 Standards Working Group — 
Recommended Practice for the Evalua¬ 
tion of CASE Tools. 


Computer Society service awards. 

Many of the service awards presented at 
Compcon were announced in earlier is¬ 
sues of Computer (see January 1991, pp. 
92-94, and March 1991, pp. 78-80). 
Awards not previously announced in¬ 
clude two Outstanding Contribution Cer¬ 
tificates, one Meritorious Service Certifi¬ 
cate, and six Certificates of Apprecia¬ 
tion, as follows: 

• Ronald H. Berlack received an Out¬ 
standing Contribution Certificate for 
“work leading to establishment of IEEE 
Standard 828-1990, IEEE Standard for 
Software Configuration Management 
Plans.” 

• Don Terry received an Outstanding 
Contribution Certificate for “outstanding 
technical achievement in the develop¬ 
ment and adoption of ISO 9945-1:1990 
and IEEE Standard 1003.1-1990.” 

• Roger Martin received a Meritorious 
Service Certificate for “outstanding tech¬ 
nical achievement in establishing con¬ 
formance-testing practices for the Posix 
standards in the US and internationally.” 

Certificates of Appreciation were 
awarded to 

• Pei Hsia, for “technical and adminis¬ 
trative leadership while serving as chair 
of the Technical Committee on Comput¬ 
er Languages.” 

• Krishna Kavi, Frederick Petry, 
Charles Richter, and Rao Vemuri for 
“dedicated service to the Computer Soci¬ 
ety Press as members of the editorial 
board.” 

• Mary Lynne Nielsen, for “dedication 
in establishing the publication guidelines 
to get the Posix standard to ISO/IEC in a 
timely fashion.” 


UPDATE 


Contributions to Update are welcome. Send news of public policy or professional issues and of industrial or 
university research to Bob Carlson, 10662 Los Vaqueros Circle, P0 Box 3014, Los Alamitos, CA 90720-1264. 


Microprocessor patent being reexamined 


Bob Carlson, Staff Editor 

Texas Instruments won a round in its 
challenge to Gilbert P. Hyatt’s patent on 
the microprocessor when the US Patent 
Office agreed to open an “interference” 
proceeding to reexamine the question of 
who invented the single-chip microcom¬ 
puter. And, at least until the outcome of 
the investigation, the patent office ac¬ 
corded Hyatt’s patent a filing date of De¬ 
cember 1977 instead of December 1970, 
as previously accorded, leaving Gary W. 
Boone, then a TI researcher, with the 
earlier filing date of July 19, 1971. 

Observers feel that the burden of proof 
now rests with Hyatt to support his claim 
to the earlier filing date. Hyatt, a fea¬ 


tured speaker at Compcon Spring 91 (see 
Conferences department, p. 105), has ex¬ 
pressed confidence that he will ultimate¬ 
ly prevail. 

The interference proceeding will no 
doubt focus on the level of detail includ¬ 
ed in Hyatt’s 1970 filing to determine 
whether it was sufficient to meet the re¬ 
quirements. Michael Slater, editor and 
publisher of the Microprocessor Report, 
noted that what Hyatt built was a multi¬ 
chip system on a breadboard, which he 
said could be built on a single chip. He 
did not have to actually produce the sin¬ 
gle-chip microprocessor to be granted the 
patent. 


Computer Museum to open new exhibit in June 


The National Endowment for the Hu¬ 
manities has awarded a $275,000 grant to 
the Computer Museum in Boston to create 
an exhibit titled “People and Computers: 
Milestones of a Revolution,” scheduled to 
open June 29. 

Through nine important milestones, the 
exhibit will trace the evolution of the 
computer from a few costly electronic gi¬ 
ants in the 1940s to the millions of desk¬ 
top computers and microprocessors in use 
today. The centerpiece of each milestone 
will be a life-size re-creation of a comput¬ 
er environment typical of a major era. The 
displays will be enhanced by films, video¬ 


tapes, and interactive computer stations. 

By interpreting the history of comput¬ 
ing in human and cultural terms, the ex¬ 
hibit is intended to encourage visitors to 
reflect on both the positive and negative 
impact of the computer on society and 
their own lives. 

With more than 75 interactive exhibits, 
including the award-winning Walk- 
Through Computer, three theaters, and a 
multimedia robot show, the Computer 
Museum draws over 150,000 visitors a 
year. In addition, the museum has begun 
exporting exhibits to other museums and 
technology centers around the world. 


US Navy announces Young Investigator awards 


Computer science faculty members 
David Dill and Andrew Goldberg at 
Stanford University and Steven Feiner 
at Columbia University have been se¬ 
lected by the Office of Naval Research 
to receive 1991 ONR Young Investiga¬ 
tor Program awards. Dill will conduct 
research in automatic verification and 
synthesis of finite-state hard real-time 


systems. Goldberg will examine issues 
in algorithm design and evaluation. 
Feiner will study automated generation 
of 3D virtual worlds for task explana¬ 
tion. 

Each successful applicant is awarded 
a three-year ONR grant of approximate¬ 
ly $75,000 per year, plus support for ac¬ 
quisition of research equipment. 
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Conference Material 

Service Desk 
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1. Conference Service Desk is in the Atrium. 

2. Banquet will be in the Governor's Hall, 

(you are on your own for all other meals). 

3. All technical sessions are in the Governor's Hall. 


Session A in Chamber I 
Session B in Chamber II 
Session C in Chambers V & VI 
Session D in Chambers III & IV 

Tutorials 1 and 5 in Chamber III 
Tutorials 2 and 6 in Chamber IV 
Tutorials 3 and 7 in Chamber V 
Tutorials 4 and 8 in Chamber VI 


4. Coffee breaks and parties are in the Atrium. 


Cocktail 
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20th INTERNATIONAL CONFERENCE ON PARALLEL PROCESSING 

August 12-16, 1991 • Location: Pheasant Run Hotel • St. Charles (West of Chicago), IL 60174 
Hotel Phone: (708) 584-6300 



IQCATION 

Pheasant Run is located In DuPage County, Illinois and is about 25 miles 
from O'Hare International Airport and 45-minutes from Chicago's loop. 
The 500-room resort hotel has various sports and health facilities. 


TfiANSPQmarm 

Van Transport from Chicago's O'Hare Airport and Midway Airport to the 
hotel is available through the hotel's Transportation Department. The rate 
for transportation between the O'Hare Airport and Pheasant Run is $20 per 
person. The rates for transportation between the Midway Airport and 
Pheasant Run are: $20 for one, $15 each for two, and $10 each for three or 
more persons each way. You should make advanced reservations with the 
hotel by dialing 1-800-924-7376 to be picked up at the airport. All of the 
vans are brown and tan with a Pheasant Run logo on the side. If you have 
any questions or need assistance, call the Transportation Department at 1- 
800-924-7376. 


ADDITIONAL COPIES 

The three-volume sets of the 1991 ICPP Proceedings may be ordered from 
CRC Press. 

Telephone: 1-800-272-7737 (all residents except Florida) 

1-407-994-0563 (Florida residents) 

Order Book Code #190. 


RFG1STRATION 

Pre-registration is mandatory because the limited space is being reserved 
for Conference participants only. THE REGISTRATION DEADLINE IS July 24, 
1991. Register early to assure your accommodation. 

TOU MUST SEND TWO CHECKS: 

tutorial, payable to "International Conference on Parallel 
Processing." See the registration form. Qua Jar a auarantfled room 
reservation, in the amount of one night deposit per room, payable 
to "Pheasant Run". Please mall both checks to PHEASANT RUN, P.O. 
Box 64. St. Charles. Illinois 60174, Attn: Ms. Carol Mlelczarek. 
Phone (312) 584-6300. 

Both the registration fee and the deposit for guaranteed reservations will 
be refunded only if a written cancellation is received on or before July 24, 
1991. (See important Notice above.) 

FURTHER INFORMATION 

For additional information on the technical contents of the Conference, 
please contact: Dr. C. L. Wu. (512) 471-4085. Dept, of Electrical & 
Computer Engg.. The University of Texas, Austin, TX 78712. 

For information or assistance regarding accommodations or registration, 
please contact: Ms. Carol Mielczarek, Pheasant Run. P.O. Box 64, St. 
Charles. Illinois 60174. Phone (312) 584-6300. 


Sponsored by The Pennsylvania State University 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, University of Massachusetts-Boston. Send review submissions to MOCO Inc., 770 Country Way, N. Scituate, MA 02066; 
Compmail, r. eckhouse; Bitnet, eckhouse@cs.umbsky. 


When backing up is the thing to do 


Product reviewers continually install, 
evaluate, and remove new hardware and 
software. Whether we are updating an 
older version of software, replacing one 
utility with another, or replacing a hard 
disk, we constantly face significant 
changes to our systems. Too often things 
don’t work out the way we expect, and we 
urgently need to restore the system to its 
previous state. 

Backing up files before making a 
change is absolutely necessary. We have 


learned — as you well should have by 
now — that a reliable backup is the only 
way to proceed. Things can suddenly go 
“bonk” in the night, you can mistakenly 
delete files or whole directories, or the 
ubiquitous virus may creep into your sys¬ 
tem. Without a backup, you almost al¬ 
ways have to start from scratch. 

It’s equally important that you regular¬ 
ly back up files residing on large disks — 
with as little hassle as possible. Consider 
a 330-Mbyte hard disk that is 80 percent 


full. Using a disk-based backup scheme 
with a good data-compression capability 
requires more than 150 floppy disks, as¬ 
suming a 40 percent compression rate. 
Moreover, you can’t just go away and let 
the backup take place by itself. You have 
to keep switching floppies. 

The following reviews give yoU some 
alternatives to floppy backup. To that end, 
we offer you three choices in the medium 
of magnetic tape: two cartridge tape 
drives and a nine-track open reel drive. 


Cartridge tape versus reel tape 

T.L. (Frank) Pappas, AWEB Software Technology 


I used a 33-MHz IBM PC AT/386 to 
review a cartridge tape drive and a nine- 
track open reel drive. The PC has a 330- 
Mbyte hard disk with a 16-ms average ac¬ 
cess time. I performed backups under 
MS-DOS 3.3 and SCO (Santa Cruz Oper¬ 
ation) Open Desktop 1.1 Unix. Under 
MS-DOS, I backed up and restored 29.2 
Mbytes of data on the single MS-DOS 
partition (drive C) allocated on the disk. 
Under SCO Unix, I backed up and re¬ 
stored a 54-Mbyte directory. 

Tape units serve other purposes besides 
backing up data. A considerable amount 
of source code is available only by tape. I 
requested source code from several orga¬ 
nizations to see how easy it would be to 
read the tapes and cartridges. The source 
includes the Simtel-20 Ada repository, the 
STARS foundation software, the Unix 
TeX distribution from the University of 
Washington, the Arcadia software from 
the University of California, Irvine, and 
the Cornell Synthesizer Generator. 

I had no problems worth mentioning in 
reading these tapes or cartridges. In a fu¬ 
ture issue, I will discuss this source code 
and some other sources in depth to let you 
know whether they are worth getting. 

An easy-to-use cartridge tape. The 

File Safe Tape Series 7150 cartridge unit 
from Mountain Computer has a QIC-02 
controller board that fits into a short XT 
slot. (The QIC-02 is the standard control¬ 
ler for most cartridge tape units.) The 


7150 plugs into a port at the back of the 
board. You can change the jumpers to 
match your hardware configuration, but 
I didn’t need to. 

This 7 x 4 x 15-inch unit fits nicely 
next to a standard-sized AT cabinet. The 
front of the unit has a door for the car¬ 
tridge, a power-on light, and a status line 
that signals green when the unit is ready 
and yellow during tape operation. The 
power switch in the back is the only con¬ 
trol on the unit. 

The 7150 can read from and write to a 
variety of tape cartridges. For example, it 
can write 150 Mbytes of data to a DC 
600XTD or DC 6150 cartridge and 120 
Mbytes to a DC 600A cartridge. It can 
also handle smaller tapes such as the 45- 
Mbyte DC 300XLP. The specifications 
claim a 1-Mbps data-transfer rate on a 
stand-alone system. 

Archiving under Unix. All I had to do 
to ready the unit under SCO Unix was to 
install the controller board and plug in the 
7150 (SCO Unix has a QIC-02 driver). 
Under Unix, the tape command, among 
other things, lets you retension first-time 
or long-unused tapes to avoid I/O errors. 

I used the tar command for backup and 
restore. I used relative path names in the 
backup of directory /u/local by changing 
to the /u directory and then entering the 
command 

tar cv local 


The options cv mean “create at the begin¬ 
ning of the tape,” using “verbose mode” 
(to list backed-up files at the terminal), 
and “write to the default archive device.” 
To restore the entire archive, say, to /usr/ 
local requires changing to directory /usr 
and entering the command 

tar xv 

The restore command requires less in¬ 
formation than the backup command, 
since tar reads the directory information 
from the tape. 

Both commands use the default archive 
device /dev/rctO. (Here, ct means the car¬ 
tridge tape drive and 0 means the first 
drive.) 

For system administrators, SCO Unix 
provides a menu-based approach to simplify 
backing up and restoring file systems. Since 
this isn’t a standard Unix procedure, I won’t 
go into it. Unix also provides the system ad¬ 
ministrator a programmable reminder to 
back up the system. 

Using the Unix time command to mea¬ 
sure program execution to the nearest 
minute, the backup took me 14 minutes, 
while the restore took 23 minutes. The 
overhead in the Unix file system accounts 
for the increased restore time. 

Archiving under MS-DOS. Since MS- 
DOS does not have any native support for 
tape units, Mountain provides File Safe 
menu-driven backup software. BAT files 
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perform typical backup and restore opera¬ 
tions. The software requires 2.2 Mbytes 
of disk space. 

The installation is not painful, requiring 
little user interaction. After installation, 
you can set up defaults to facilitate the 
normal backup and restore processes. 

I prefer using the menu version under 
MS-DOS and the tar command under 
Unix. With Unix, you use tar a great deal. 
Not only does it work with tapes, but you 
can also use it with floppies or even the 
hard disk (since tar writes a file to the de¬ 
vice). Most of the software that I use in 
Unix, even commercial packages, is de¬ 
livered in tar format. 

Under MS-DOS, the File Safe software 
is just one more thing that you have to re¬ 
member how to use. Rather than trying to 
remember that “tape sbk c:” and “tape srs 
c:” are the backup and restore commands 
I should use (or whether I should set other 
options), I just go to the menu. 

The menu interface is pretty straight¬ 
forward. Although it does have a few 
awkward features, they are not really 
worth going into. I will say that a pull¬ 
down menu system would make the inter¬ 
face friendlier. 

The File Safe software, which seems to 
be standard across the Mountain backup 
unit series, offers a variety of features and 
utilities. The utilities provide for reten¬ 
sioning and verifying a tape. You can also 
set a reminder that it is time to back up 
your files. 

File Safe provides two kinds of backup 
and restore operations. The selective 
backup and restore typically lets you 
choose the files you want to back up and 
restore, including the entire drive. The 
full backup and restore differs in that an 
image of the drive, rather than of individ¬ 
ual files, is written to or read from the 
tape. This is quicker, but less versatile, 
than the selective backup. 

In general, you can append your back¬ 
ups to the tape, labeling and describing 
each volume separately. You can search 
for a particular volume and restore from 
that, or you can request a list of volumes 
and choose one to restore. You can also 
prevent system or hidden files from being 
written to or read from the tape, and you 
can ask to be prompted before reading or 
writing such files (which include read¬ 
only files). 

The 29.2 Mbytes that I backed up and 
restored to drive C did not include Moun¬ 
tain software or the two MS-DOS system 
files. It took about 6 minutes to back up 
this data and another minute and a half to 
rewind the tape (these operations are in¬ 
cluded in the Unix statistics as well). Re¬ 
storing the data to disk, after erasing the 
directories, took only another half minute, 
so the entire backup and restore took 8 
minutes. 


Just looking at the numbers, and forget¬ 
ting MS-DOS partition size limits, the 54 
Mbytes in the Unix example should have 
taken about 14 minutes. The 14 minutes 
required by Unix is right on target. How¬ 
ever, restoring 54 Mbytes would have tak¬ 
en about 15 minutes under MS-DOS, so 
the 23 minutes required under Unix is 
about 50 percent higher. 

The unit costs $2,295, which may be 
more than some people can pay for a 
backup device, but if you or your organi¬ 
zation can afford the price, it’s worth the 
money. The unit provides reasonably fast 
backups (which you perform more often 
than restores), and you can access a vari¬ 
ety of source code. 

Readers can contact Mountain Comput¬ 
er Inc., 10 Victor Sq., Ste. 500, Scotts 
Valley, CA 95066; (800) 458-0300. 
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A powerful open-reel system. The 

Tape Linx 9914 nine-track tape sub¬ 
system from Overland Data consists of an 
M49914 tape drive and a Txi-16 intelli¬ 
gent controller. The Txi-16, with a zero- 
wait-state microprocessor, a 1-Mbyte 
cache, and a 16-bit architecture, requires 
a full AT slot. 

The drive supports densities of 800, 
1,600, 3,200, and 6,250 bpi and NRZI, 

PE, DPE, and GCR modes. It can operate 
in streaming or start/stop modes. The lat¬ 
ter forces a delay between blocks so that 
tape-positioning commands do not arrive 
at the drive too soon. The specifications 
claim a data-transfer rate of 2 Mbps burst. 

The 9914 is physically enormous. Its 
19 x 9 X 22-inch footprint is significantly 
larger than that of a full-sized AT, as well 
as being 50 percent greater in height. At 
83 pounds, it is definitely not a desktop 
unit. With a list price of $11,295, it is also 
not something you would buy for home 
use unless you have a small business and 
need to read and write a large variety of 
nine-track tapes. If your company or orga¬ 
nization requires that type of nine-track 
capability and can afford the unit, this is a 
really good system. 

You need special software to use the 
9914 under MS-DOS or any AT&T- 
based Unix, such as SCO Unix. The in¬ 
stallation under both systems is pretty 
straightforward. The controller has typi¬ 
cal jumpers that you can set, but, again, I 
didn’t have to. 

The MS-DOS software installation 
was uneventful. But under Unix, I had to 
remove the QIC-02 device driver using 
the mkdev tape command and install the 
new driver using the Unix installpkg pro¬ 
gram. Of course, then I had to build a 
new kernel and install it, but installpkg 
easily handled that. The MS-DOS soft¬ 
ware requires 1.2 Mbytes, while the Unix 


software only requires 0.2 Mbyte. 

Because the 9914 is a self-loading sys¬ 
tem, it makes a loud noise when it loads 
and unloads a tape, which is something 
to consider if the unit would stand near a 
desk. It sounds like the forced-air hand 
dryers you find in public rest rooms. 

The performance of the 9914 and the 
Txi-16 is superior to that of the Moun¬ 
tain 1750. Under MS-DOS, the 29.2 
Mbytes took about three minutes to back 
up and five minutes to restore. Under 
Unix, it took about 8 minutes to back up 
the /u/local directory and 14.5 minutes 
to restore it. I used a density of 6,250 bpi 
when creating these tapes. The company- 
supplied Unix driver for the nine-track 
tape is especially designed for the Txi-16 
with the 9914 and takes full advantage of 
its high-speed capability. 

For the most part, the Unix software 
consists of the device driver needed to 
support the nine-track tape. Here the tar 
commands would be written to /dev/mtO 
instead of /dev/rctO. The shell script pro¬ 
vided for performing backups is nothing 
special. A basic tape-test program is also 
provided. The C source code for this test 
program and for a tape-positioning pro¬ 
gram is provided to illustrate how to 
write your own tape-oriented programs. 

The MS-DOS software is much more 
elaborate. Although the software con¬ 
tains command-line versions of the major 
programs, the user-friendly menu-driven 
versions are much better, with pull-down 
menus. The backup and restore programs 
provide basic features. In fact, except for 
the added user friendliness and the nine- 
track functions such as tape speed, there 
really is not much difference between the 
Mountain and Overland backup and re¬ 
store capabilities. 

The Overland Data software can handle 
various tape formats. It can read and write 
ASCII or EBCDIC tapes, using ANSI or 
IBM labels. The software also provides 
conversion between ASCII and EBC¬ 
DIC, and various end-of-line conver¬ 
sions. 

Overland Data has added two really 
good features to its MS-DOS software 
that Mountain should consider. The soft¬ 
ware can examine the contents of a tape, 
block by block and file by file. It’s a 
great way to figure out what is on a tape 
that you don’t know anything about. The 
software can also read and write Unix tar 
tapes. Not all of tar’s bells and whistles 
are provided, but the ones you expect un¬ 
der MS-DOS are there. For example, to 
extract the files on a tape, you enter the 
command 


This is a great feature for someone who 
uses both MS-DOS and Unix or who 
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has to process Unix tapes. 

As many of you know, Unix file 
names can be longer than those in MS- 
DOS. The MS-DOS tar gets around this 
by renaming these files and writing a 
message to the screen telling you which 
file had to be renamed and its new 
name. This, along with the verbose op¬ 
tion v, tells you all you need to know to 
sensibly rename such files. It would be 


nice to enter the command 
tar xv > file.log 

to get all information (as described in 
the user manual), but, unfortunately, the 
MS-DOS tar does not write to standard 
output. It seems to write directly to the 
terminal instead. 

The MS-DOS version also supplies 


custom tape programs written in Turbo 
Pascal, Microsoft Quick Basic, IBM 
Professional Fortran, Microsoft Fortran, 
and Microsoft C as part of the compa¬ 
ny’s MS-DOS Programming Toolkit. 

Readers can contact Overland Data 
Inc., 5600 Kearney Mesa Rd., San Di¬ 
ego, CA 92111; (619) 571-5555. 
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The low-price leader 

Richard Eckhouse, University of Massachusetts-Boston 


When I purchased my first PC with a 
hard drive, choosing the vendor was 
easy. I picked the one that offered a tape 
backup as part of the system configura¬ 
tion. Maybe it was my minicomputer and 
mainframe experience, or my firm belief 
in Murphy’s Law. Either way, I knew 
that I wanted the security of an easy, reli¬ 
able, efficient tape backup for that sys¬ 
tem — and all future systems. 

My first tape backup was limited to 10 
Mbytes, was not very user friendly, and 
required that I reformat the tapes regular¬ 
ly to make sure that restores went on 
without a hitch. Occasionally, I’d try one 
of the new hard-disk-to-floppy utilities 
just to reconfirm my decision that a tape 
was more convenient. As I added PCs to 
my collection, I’d purchase the latest in 
tape backup units because the tape ca¬ 
pacity was becoming inversely propor¬ 
tional to the unit price. 

The Jumbo-20, a 250-Mbyte tape 
backup from Colorado Memory Systems, 
is my backup device of choice. It is easy 
to use, full of features, reliable, and — 
most of all — low priced. At $499 retail 
(with a street price of only $349), its 
most serious competition is the Jumbo- 
10, a 120-Mbyte backup from the same 
company that can be had mail order for 
around $249. Is doubling your storage 
capacity worth $100? The choice seems 
easy. 

To be fair, let me point out that the 
physical capacities of the Jumbo units 
are actually only about one-half of what 
I’ve just said. The 250-Mbyte unit uses 
120-Mbyte tapes and provides data com¬ 
pression to gain the additional capacity. 
The compression occurs in hardware or 
software, using the Stac algorithm (re¬ 
viewed later), depending on whether you 
purchase a separate interface board. The 
TC-15 board includes the Stac chip and 
directly connects the board to the drive. 
Although the board takes up one slot, 
this arrangement increases the transfer 
rate between the hard disk and the tape 
drive. Or, you can connect the tape drive 


by cable to the floppy drives (as in drive 
B), but you must use the software ver¬ 
sion of the compression algorithm and 
are limited to the transfer rate of the 
floppy controller. 

I didn’t find one method clearly better 
than the other. Backup times are quite 
reasonable on the 486/25 in which the 
backup unit was installed. Had I put the 
backup in an older machine, such as an 
XT where the floppy controller runs half 
as fast (again about half as fast as the 
Jumbo controller), I would have clearly 
gained significant transfer speed using 
the data path between the controller and 
backup drive. Of course, a vacant slot is 
required on the backplane. The decision 
becomes a configuration and personal 
question, since you pay more for the con¬ 
troller card ($129.95 without hardware 
compression and $299.95 with it for the 
ISA version, or $399.95 for the Micro 
Channel version). Also, in the case of the 
ISA version with compression, you need 
to dedicate an interrupt, an I/O port, and 
two DMA channels for both control and 
compression. 

To give you some idea how fast this 
unit is, I tested it on the 486/25 equipped 


with an ESDI 156-Mbyte, 16.2-ms aver¬ 
age seek drive, equally partitioned into 
logical drives C and D. The operating 
system is MS-DOS 4.01. With approxi¬ 
mately 22.5 Mbytes of disk space hold¬ 
ing 988 files, it took 4 minutes and 28 
seconds to back up drive D. I used a 3M 
DC2120 cartridge tape rated at 120 
Mbytes that sells for around $25. 

Hardware and software installations 
are very easy. My unit came with rails 
for mounting into a standard 5.5-inch 
half-height bay. You slide the drive into 
your computer, plug in the interface 
board, cable it to drive, attach a power- 
and-ground cable, and close up your ma¬ 
chine. The software comes with its own 
installation procedure that configures the 
jumperless interface board. From then 
on you can use the drive through a 
menu-driven interface or with a batch 
file. 

By the way, the manuals that come 
with each unit are thorough, well illus¬ 
trated, and fully indexed. Customer sup¬ 
port over an 800 number is courteous, 
knowledgeable, and honest to a fault. For 
example, I called to see if there was 
some way to add the backup drive to a 



Jumbo 250 tape backup system. 
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computer with two floppy drives already 
installed. The answer was “Yes, a cable 
is available, but you can buy or build it 
cheaper yourself!” 

The software that comes with the Jum¬ 
bo DJ-20 is quite versatile and provides 
multivolumes per tape, among many oth¬ 
er capabilities. The menu interface gives 
you three alternatives: backup to tape, re¬ 
store to disk, and select utilities. In the 
backup-to-tape menu, you can choose se¬ 
lective (where you indicate the files to 
back up), modified files (those with the 
archive bit set), and total. After trying 
these commands from the menu, I used 
the command-line options to create two 
batch files: one to do a complete backup 
and one to back up only changed files. 
Because I could specify a “tag” file that 
in effect says “Don’t back up the operat¬ 
ing system or the Windows swap file,” I 
didn’t include unnecessary files. 

Tagging options also include files in 
subdirectories and before/after dates. By 
completing a schedule menu, you can 
further provide for automatic and unat¬ 
tended backups, specifying the type, 
drive, days of the week (or date), and 
time. When backing up volumes, you can 
also give them titles (useful during a re¬ 
store) and password protection. 

Restoring is equally easy, beginning 
with the screen that lists the volumes 
stored on the backup tape. A selective re¬ 
store makes it easy to get back a single 
file you might have “munged,” or you 


can tag multiple files, directories, or the 
entire volume. Some restore and backup 
options that you set in the utilities menu 
handle issues like compression (or not) 
and overwrite during restore. 

The utilities menu lets you choose tape 
status (when last formatted, tape format, 
number of volumes, etc.). Bear in mind 
that the DJ-20 uses an industry standard 
QIC-80 format so that other tape soft¬ 
ware can actually read this tape. Also, 
the drive can read DJ-10 or QIC-40 
tapes. The utilities menu lets you quickly 
erase the tape and give it a new label, 
format a tape, perform a secure erase of a 
tape with data on it, compare the tape to 
disk files, and configure or set up the 
hardware or software. 

Note that the drive retensions the tape 
whenever it is inserted. Thus users often 
leave the tape in the drive and remove it 
only to use another tape. This is probably 
a bad way to use the drive, since the rub¬ 
ber drive roller might become flattened 
by a tape that is not referenced for hours 
or days. Equally important is the clean¬ 
ing of the drive’s moving parts and tape 
heads. The manual explains when and 
how often this should be done. 

It’s hard for me not to rave about this 
tape backup just like other reviewers 
have because it is a price/performance 
leader. Unlike other reviewers, I’d give it 
more than a perfect score, pegging it at 
12 (out of 10). I’ve been using the drive 
for several months to restore any file, 


Networking at the high end 

Giovanni Perrone, President, GP Systems 


Netware 386 tops off Novell’s family 
of local area network operating systems. 
Version 3.0 shipped in September 1989 
as the first 32-bit, 386-based LAN oper¬ 
ating system. The system was designed 
specifically as a platform for network 
computing and provided improved per¬ 
formance, higher security, greater reli¬ 
ability, and increased protocol indepen¬ 
dence. 

Version 3.1 provides a formidable ar¬ 
ray of networking capabilities in a much- 
improved package. In terms of features, 
performance, and overall capability, it 
meets or exceeds anything competing 
vendors have to offer. It also has a few 
notable limitations. 

First, the bad news. The following lim¬ 
itations could impact a purchase deci¬ 
sion, especially in smaller firms. Because 
of this level of importance, I feel it’s 
proper to address these issues early. 


(1) Growing pains. Netware 386 has 
been an evolutionary product. Ver¬ 
sion 3.1 is a major improvement 
over 3.0, but as I write (January) 
Novell is just starting to ship a few 
major and previously promised 
components, such as the Name 
Service, Remote Management, and 
Macintosh Netware 386 Loadable 
Modules (NLMs). 

(2) Dedicated server. Netware 386 
requires a dedicated file server. In 
large LAN configurations, this 
spreads performance advantages of 
the “hotter” 386 or 486 systems 
through an optimized network op¬ 
erating system to many worksta¬ 
tions of lower performance. But a 
smaller firm is often reluctant (or 
can’t afford) to dedicate its best 
system as an exclusive file server. 


multiple files, or an entire hard disk after 
a serious failure (or accidental erasure) 
on the hard drive. The unit is fast and so 
easy to use that I perform an incremental 
backup daily and a total backup once a 
week. All it takes is one tape, but I use 
two — with one tape serving as a fall¬ 
back for the previous week. In fact, I 
haven’t needed it. 

The ads for this backup unit proclaim 
“Jumbo performance for peanuts,” to 
which I add “peace of mind guaranteed.” 
I now own several Jumbo drives to pro¬ 
tect my systems. Compatibility hasn’t 
been a problem with the machines (from 
my first 8088 to my current 486/25, each 
from a different manufacturer), and I’ve 
found that the Jumbo is compatible with 
my Artisoft LAN. Thus, I only had to 
buy one drive for all machines on my 
network, which saved me enough money 
to add extra nodes. Also, although I did 
not test it, the Jumbo is fully network- 
compatible with Novell, 3COM, and PC 
Net. Optional software for Unix systems 
runs with SCO, Interactive, AT&T, and 
Intel systems Version 5.0. An extensive 
Compatibility and Accessory Guide lists 
much of this information along with cur¬ 
rent pricing. 

Readers can contact Colorado Memory 
Systems, 800 S. Taft Ave., Loveland, CO 
80537; (303) 669-8000; fax (303) 667- 
0921. 
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(3) Complexity. The numerous fea¬ 
tures and capabilities of this ver¬ 
sion produce complexity. After 
spending several months working 
with the system and documenta¬ 
tion, I can easily see why. Admit¬ 
tedly, the company has greatly 
simplified installation and im¬ 
proved documentation, but instal¬ 
lation still requires a lot of user 
preparation. The approach to net¬ 
work setup is distinct and purpose¬ 
ful, with emphasis on preplanning 
and network design. This is exact¬ 
ly as it should be for a high-end 
product intended for large, sophis¬ 
ticated networks. 

(4) Price. Pricing is consistent with the 
features offered to large LAN in¬ 
stallations that can fully exploit 
them. For smaller firms looking for 
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an entry-level 32-bit solution, pric¬ 
ing is prohibitive. Novell surely 
must have already recognized this. 

Now let’s get on with the good news 
— and with Netware 386, there is plenty 
of it. 

This system is not just a modified ver¬ 
sion of Netware 286. It is completely 
new and designed specifically for 386- 
and 486-based systems. A significant dif¬ 
ference between Netware 386 and the 
previous versions is that it takes full ad¬ 
vantage of the Intel 386 32-bit micropro¬ 
cessor. It uses protected mode opera¬ 
tions, 32-bit instruction and data paths, 
and no memory segmentation. It exploits 
the 386 environment to provide enhanced 
features such as 

• 4 gigabytes of physical memory (the¬ 
oretical maximum), 

• 32 terabytes of disk storage (theoreti¬ 
cal maximum), 

• 4,000 concurrent connections (3.0 
had 250), 

• 100,000 open files, 

• dynamic memory configuration, and 

• 32 disk volumes (one capable of 
spanning 32 disks). 

In addition, the system is now an 
“open server platform” that easily ac¬ 
commodates such customized enhance¬ 
ments as communication and service pro¬ 
tocols, file and directory systems, 
naming conventions, and LAN drivers. 

Users can customize a Netware 386 
file server by using the NLMs and the 
Open Data-Link Interface (ODI). NLM 
programs are often written by users and 
loaded into server memory to become an 
integral part of the software, adding a va¬ 
riety of services. ODI specifications let 
such multiple communications protocols 
as IPX/SPX, TCP/IP, and Apple Talk 
share the same driver and adapter. 

Novell has positioned Netware 386 as 
the cornerstone of its new network com¬ 
puting strategy. The company identifies 
the Netware Open Systems architecture 
for network computing as a logical ex¬ 
tension of PC-based work-group comput¬ 
ing. The latter type of computing allows 
resource sharing among users by provid¬ 
ing a platform — a network file server 
and operating system — from which they 
can access resources and data. The net¬ 
work server architecture maintains a 
user’s view of local or resident resources 
and data, but adds important features like 
management services, security, and data 
integrity. 

Network computing has a much broad¬ 
er scope and more diverse set of ele¬ 
ments than mere integration of PCs into a 
network. It integrates local and wide area 
network technologies with the goal of 


providing connectivity in a multivendor 
environment. This concept is based on 
the evolutionary needs of distributed pro¬ 
cessing and provides a highly flexible ar¬ 
chitecture that supports the connectivity 
requirements between work-group sys¬ 
tems and existing minicomputers and 
mainframes. 

A Netware 386 server requires at least 
2 Mbytes of RAM divided initially 
among DOS and the Netware 386 operat¬ 
ing system. NOS uses a portion of RAM 
for cache buffers. The default 4-Kbyte 
cache buffer size can be increased at 
startup. The server uses cache buffers to 
improve performance of several of its 
operations. Netware 386 provides dy¬ 
namic memory allocation, making it un¬ 
necessary for an installer to allocate 
server memory for cache blocks and 
buffers. 

The Netware 386 hard disk can be or¬ 
ganized into volumes, partitions, and 
segments. The server can support a total 
of 32 volumes; a volume has 1 to 32 seg¬ 
ments. A segment can use the entire 
physical disk, or only a portion, but it 
can’t span hard disks. The disk further 
divides into partitions. A hard disk used 
to start up the system is usually config¬ 
ured to contain a DOS partition and a 
Netware 386 partition. The DOS parti¬ 
tion is the active one that allows the 
server to boot DOS before booting NOS. 

The package also contains several new 
features for organizing files and directo¬ 
ries. A file called Directory Table exists 
for each volume. It divides into one or 
more directory blocks and is always 4 
Kbytes, regardless of the disk allocation 
block size for that volume. A directory 
block can contain up to 32 128-byte en¬ 
tries that store information about files, 
directories, and other related entities. A 
maximum of 65,536 directory blocks per 
volume is supported. 

Netware 386 also supports multiple 
name spaces for the files stored on a vol¬ 
ume. Each file has a DOS file name 
stored in a file entry in the Directory Ta¬ 
ble. Multiple name spaces provide multi¬ 
ple directory entries to let DOS, Macin¬ 
tosh, Unix, or OS/2 workstation 
operating systems create and maintain 
files using their own naming conven¬ 
tions. Other new file features include 
support for Sparse files (sometimes cre¬ 
ated by databases) to minimize wasted 
disk space and Salvage files to improve 
the recovery of deleted files. 

I am very impressed with the new fea¬ 
tures and improvements in Netware 386 
Version 3.1. Key improvements are 

• file and directory security; 

• the Bindery (a database of resources 
and uses); 

• Accounting Services; 


• System Reliability with an Integral 
Transaction Tracking System and 
System Fault Tolerance; 

• Streams Interface (based on AT&T 
Streams of Unix System V); 

• Print Servers supporting three differ¬ 
ent configurations: NLM, Dedicated 
Workstation, and Value-Added Pro¬ 
cess, with up to 16 printers and four 
different print queue service modes 
for each printer; 

• New (22) and Modified (80) utilities 
combined with 20 unmodified and 9 
removed utilities; 

• an Expanded Netware Core Service 
protocol language that still supports 
most Netware 286 (Version 2.15) 
NCPs; and 

• new libraries and expanded library 
calls. 

Testing the package in my modest, 
small firm, software research lab hardly 
scratched the surface of all these high- 
end network computing capabilities. My 
testing was PC-based and exercised the 
work-group computing aspects of the 
program. Although I do have a represen¬ 
tative collection of PC workstations, I 
couldn’t explore the mainframe and 
minicomputer linkages. 

The installation process involved the 
following steps: 

(1) Planning the network configura¬ 
tion. Identify the file server and 
workstations to be used, making 
sure the proper interface adapter 
boards, network cables, and termi¬ 
nators are available. 

(2) Installing the network hardware. 
This involves actually installing an 
interface adapter board into each 
server and workstation, and con¬ 
necting them with cables. 

(3) Preparing the file server. Unless 
the server contains a Netware- 
ready hard disk, a Netware parti¬ 
tion must be created for NOS. 

(4) Installing the software. Install 
NOS on the file server and gener¬ 
ate and install the software re¬ 
quired for each workstation. 

(5) Operating and expanding the 
network. After the basic network 
is up and running, install such fea¬ 
tures as one or more print servers 
and additional file servers and 
workstations. 

The initial chore of installing a small 
network is wading through the intimidat¬ 
ing collection of manuals to zero-in on 
the quickest startup approach. Unfortu¬ 
nately, the documentation — as well as 
the software — is oriented toward a large 
LAN installation. Emphasis is on plan¬ 
ning and site preparation, certainly the 
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correct approach for a large installation. 
Novell does provide a Quick Path Card 
at every major installation step, but these 
otherwise excellent cards simply don’t 
provide an overview of necessary steps. 
There is just no quick startup documenta¬ 
tion, which is especially frustrating for 
the “small” user. I expect to see that 
change in the coming Netware 386 entry- 
level system (ELS) release. 

I designated an IBM PS/2 Model 80 as 
a server. Novell has optimized two new 
32-bit Ethernet interface adapter boards 
for use with Netware 386: the NE/2-32 
for Micro Channel Architecture (MCA) 
buses and the NE3200 for Extended In¬ 
dustry Standard Architecture (EISA) 
buses. I installed the NE/2-32 in a PS/2 
32-bit slot, copied the supplied configu¬ 
ration file, and updated the reference 
disk. It was an absolutely painless pro¬ 
cess — as in most PS/2 installations. 

Each interface card includes lengths of 
thin-wire (RG-58A/U) Ethernet cable 
and T-connectors for easy cabling. You 
must place your own terminators on the 
T-connectors at each end of the LAN. 

My 115-Mbyte hard disk contained 
dual-boot OS/2 Extended Edition 1.2, 
DOS 4.02, Windows 3.0, and quite a col¬ 
lection of application software. Conse¬ 
quently, I was very reluctant to reparti¬ 
tion and format the hard disk. Of course, 

I could have backed up the software (I 
did back up all data files), but instead I 
decided to wipe the hard disk clean. In 
retrospect, I feel the housekeeping did 
both of “us” good. 

After I completed the server disk parti¬ 
tioning, I booted DOS and installed Net¬ 
ware to boot from the hard disk (versus a 
floppy). The program copied several sys¬ 
tem files to the root directory of the boot 
drive (C) and a file server boot file 
(SERVER.EXE). The file server required 
a name and internal network number (I 
used IBM PS/2 and the number 1, in the 
spirit of keeping life simple). I then load¬ 
ed PS/2 ESDI disk driver software. (A 
disk set utility is provided for external 
disk subsystems.) At this point (some op¬ 
tional step omitted), I could run the In¬ 
stall program. Keep in mind that this en¬ 
tire installation process has been 
significantly improved over previous 
versions of Netware. 

After loading the Install program, you 
must create the disk partitions or accept 
existing defaults. Next, you create and 
mount volumes and copy the system and 
public files from the remaining installa¬ 
tion floppies. Now you can load the LAN 
drivers (like NE232 for the NE/2-32 
board) and other NLMs. You designate 
the optional name space support with a 
command like: 

ADD NAME SPACE MACINTOSH TO VOLUME MAC 


A “small” installation 
reduces worry 
about conflicts 
between workstation 
devices. 


At this point, you have to bind the In¬ 
ternetwork Packet Exchange software to 
the LAN driver and assign a network 
number. IPX uses the LAN driver rou¬ 
tines to control the network board for 
data delivery. Returning to the Install 
program allows the simplified creation of 
server startup files (AUTOEXEC.NCF 
and STARTUP.NCF). The server is now 
ready (unless you missed a step or other¬ 
wise goofed). 

Optional follow-up steps include al¬ 
lowing unencrypted passwords, perform¬ 
ing a Macintosh installation, copying 
Netware 386 utilities to Netware 286 file 
servers, and further customizing your 
configuration. You’ll undoubtedly want 
to set up a workstation to see if you are 
communicating (“LANing”). 

My workstations are an IBM PC XT- 
compatible Compaq portable with a hard 
disk, a PC AT, and a Compaq Deskpro 
386-16, all DOS based. Novell provides 
both 8-bit (NE1000) and 16-bit 
(NE2000) Ethernet boards for these 
PC and ISA bus computers, and a 16-bit 
(NE/2) Ethernet board for MCA ma¬ 
chines. Since the basic installation steps 
are similar for each machine, I’ll walk 
through the Deskpro 386 workstation 
setup. 

A “small” installation reduces worry 
about conflicts between workstation de¬ 
vices. At the workstation level, conflicts 
can occur with base I/O and memory ad¬ 
dresses, and the interrupt request line. 
Alternates are jumper-configurable on 
the boards (automatically software-con¬ 
figurable on the MCA boards). In most 
cases, the default settings of 300h, IRQ3, 
remote reset disabled, and BNC connec¬ 
tor enabled will work. Inserting the ap¬ 
propriate board in an empty slot and con¬ 
necting the cable complete the 
workstation hardware installation. 

You can install workstation software 
on a floppy, on the workstation hard 
disk, or at the file server. You need two 
basic files, IPX.COM and the shell. The 
latter redirects messages from the work¬ 
station to DOS that are called 

• NETx.COM (conventional memory), 

• EMSNETx.EXE (expanded memo¬ 
ry), or 

• XMSNETx.EXE (extended memory) 


where “x” represents the DOS version (x 
for DOS 3.x is 3, so NETx.COM be¬ 
comes NET3.COM). By the way, these 
files are compatible with previous 286 
versions of Netware, which allow updat¬ 
ing of DOS workstations. 

The two files are generated with an 
SHGEN program. Once you are in the 
program, a menu prompts you to select 
LAN driver configuration options for the 
board type. Next, you create a master 
workstation floppy that contains the two 
necessary files (and any optional files 
you want, such as AUTOEXEC.BAT). 
These files can now be copied to any 
workstation using the same interface 
adapter board type. 

You are finally ready to boot the work¬ 
station and log into the file server. How 
sweet it is when you get it right the first 
time! The other types of interface adapter 
boards are installed in a similar fashion. 

A Netware print server executes print¬ 
er jobs from a print queue and sends 
them to the appropriate network printer. 
The print queue resides on a file server, 
and the print server attaches to the file 
server and has a network printer attached 
to it. Print jobs are sent from a network 
workstation to the print queue on the file 
server. The queue stores the job until the 
print server can print it. The print server 
moves the job from the queue to the 
printer. 

As previously mentioned, each type of 
print server can support up to 16 printers 
and service the queues of as many as 
eight file servers. The three types of print 
servers increase configuration flexibility. 
The NLM print server (PSERVER.NLM) 
loads directly into the file server. It links 
to NOS and sends print jobs directly 
from file server print queues to the as¬ 
signed printers. 

The dedicated DOS workstation print 
server (PSERVER.EXE) reduces the 
load on the file server by offloading 
print server tasks to a workstation. 

The value-added process print server 
(PSERVER.VAP) is available for use 
on a Netware 286 Version 2.lx file serv¬ 
er or an external bridge. A remote printer 
program (RPRINTER.EXE, a TSR) al¬ 
lows the print server to use a printer at¬ 
tached to a workstation as a remote net¬ 
work device. And Netware printing 
utilities provide a full range of functions 
for setup, control, and monitoring of net¬ 
work printing. 

I had a problem deciding when to stop 
with this review. So far, I’ve just 
skimmed the surface. What’s the bottom 
line? Netware 386 is super! But I can 
only recommend it to users who are cer¬ 
tain their current or near-future needs re¬ 
quire high-end capabilities. These users 
should also be willing to become techni¬ 
cally immersed in the process. The other 
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alternatives are to get some Netware 
training, have the package installed by a 
certified Netware 386 engineer, or settle 


for a lower cost network. 

Readers can contact Novell Inc., 122 
E. 1700 South, Provo, UT 84606-9974; 


(801) 379-5900; price $7,995. 
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Death, taxes, and full hard disks 

Quentin Fennessy, ITP Systems Inc. 


Only a few things are certain in this 
world, and one of them is that every hard 
disk will eventually fill up. It doesn’t 
matter whether you have a slowwww 
20-Mbyte disk from the days of the PC 
XT, or an incredibly fast 80-Mbyte disk 
for your 25-MHz 386. Sooner than later 
that disk will fill. 

The remedies are unpleasant. A new 
disk requires significant capital. Or you 
could clean up your hard disk. In these 
days of Turbo Pascal at 4 Mbytes, Win¬ 
dows at almost 5 Mbytes, and Harvard 
Graphics needing at least 3 Mbytes, re¬ 
ducing usage means deleting significant 
applications. Hard disks are rarely filled 
with lots of small programs but rather 
with several large ones, as in my case. I 
use an AT&T 6300 Plus with a well-aged 
Seagate ST-225 (20 Mbytes, no waiting), 
and I have a permanent dearth of disk 
space. 

Another remedy is to compress your 
data to increase free space. Stac Elec¬ 
tronics has two products that compress 
data in real time. The Stacker Coproces¬ 
sor ($229) implements the LZ-1 algo¬ 
rithm in hardware, and Stacker Software 
($129) does so in software. 

When I first read about disk compres¬ 
sion, I knew it was worth checking out. 
Claims that compression halved disk use 
tempted me. By the time I actually used 
the Stacker Coprocessor board, I expect¬ 
ed too much. I had three fears: compati¬ 
bility, reliability, and performance prob¬ 
lems. One way or another, it would not 
work out. But I was wrong. 

After a complete system backup, I in¬ 
stalled the Stacker disk compression 
hardware and software in about an hour. 
The half-length board and drivers were 
simple and took about five minutes to in¬ 
stall. Then the software took over. I start¬ 
ed with 19 Mbytes used out of 20 
Mbytes. I ended up with a total of 15 
Mbytes free, for a compression ratio of 
1.7 to 1. My old hard disk had new life. 

The Stacker software actually creates a 
large file in the root directory and incre¬ 
mentally moves most of the files on the 
disk into this file. The Stacker drivers 
then make this file appear as a logical 
hard disk — the D partition in my case. 
The compression took two steps: putting 
all files into the Stacker file and com¬ 
pletely defragmenting the disk. A Stack¬ 
er utility swaps the partition names so 
that after the machine boots from C, it is 


renamed D, and vice versa. All files in 
the Stacker partition still look like they 
are on C. 

I still had my three fears to contend 
with, but initially the unit worked fine 
(15 Mbytes extra was fine with me). 
What about compatibility, reliability, and 
performance? So far, I have found no 
problems with compatibility. Windows 
works, Checkit works, and even CHKD- 
SK performs as requested. Application 
performance seems about the same as I 
saw before. 

How about reliability? What if I lost 
all my wife’s files? I did a complete 
backup before I started, but what about 
down the road? A test in Stacker code 
detects failed boards at boot time. Then 
the software takes over, and you can still 
access all your data. 

I decided to test it by removing the 
Stacker board and booting my PC. The 
driver sent out a message about hardware 
failure, and, when I hit a key, it booted 
normally. All my files were still there. 

I ran four tests to see how hardware 
and software compression differ. I didn’t 
see what I expected. (I know everyone 
always says that, but this time it was 
true.) The tests were an XCOPY of the 
Windows 3.0 subdirectory to another 
part of the same disk, a CHKDSK of 
both C and D, the statistics from Checkit 
for disk speed, and a directory listing of 
every file on the system. The XCOPY 
took about 40 percent longer with soft¬ 
ware. The CHKDSK times were almost 
identical. The disk stats were identical 
because these controller-level tests did 
not involve the board and software. The 
directory searches were within 5 percent 
of each other. For most tests, the differ¬ 
ences between hardware and software 
compression were negligible, but when 
the program had to read every byte of ev¬ 
ery file for the directory listing, disk per¬ 
formance took a hit. This shows the 
speed advantage of the hardware 
coprocessor. 

Stacker claims hardware compatibility 
with DOS Versions 3.0 and 4.0 on any 
ISA or EISA PC. The resident software 
takes 21 Kbytes and may be loaded into 
high memory with a memory manager. 
The software version also works on 
MCA systems or portables that lack ex¬ 
pansion slots. Both versions support ST- 
506, IDE, SCSI, and ESDI disks. Stacker 
can be installed incrementally — as I did 



Stacker hardware and software. 


— or by allocating free disk space. It 
works with large volumes of up to 256 
Mbytes when installed on DOS 4.X sys¬ 
tems. Both Stacker products come with a 
90-day money-back guarantee. 

Stacker saves disk space in two ways. 
It replaces repeated sequences of bytes 
with tokens that point to a previous oc¬ 
currence of the sequence. It also stores 
small files efficiently by allocating the 
disk in 512-byte sectors rather than 2- 
Kbyte clusters. This means the average 
file wastes only 256 bytes, not 1 Kbyte 
or more. Although the compression rate 
was 1.7 to 1, more text files would in¬ 
crease this ratio. Binary EXE files have a 
more random byte distribution, and text 
files use fewer types of bytes, making 
compression easier. 

While the Stacker worked well for me, 
it is most efficient when used with larger 
disks. At list price, it would cost me 
$229 to add a 15-Mbyte capacity to my 
disk. For a little more, I could buy a 40- 
Mbyte disk with better performance than 
my old one. However, if you have an 80- 
Mbyte disk, $229 should buy you anoth¬ 
er 56 Mbytes. For small disks, a price/ 
performance comparison indicates a re¬ 
placement, while for larger ones the 
Stacker is a big win. When street prices 
are taken into account, it even looks 
good for smaller disks. 

Readers can contact Stac Electronics, 
5993 Avenida Encinas, Carlsbad, CA 
92008; (800) 522-7822. 
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Contact or send releases to Christine Miller, Computer, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264; Internet, s.c.miUer ©compmail.com 


Cray expands series, operating system 


St. Croix Corp. unveils 
486 PCs 


Cray Research’s Y-MP4E, Y-MP8E, 
and Y-MP8I supercomputers feature bal¬ 
anced architecture, an improved I/O sub¬ 
system, and a solid-state storage device. 
The MP4E features two to four CPUs 
and 32 or 64 million words of central 
memory. The MP8E features four to 
eight CPUs and up to 256 Mwords of 
central memory, while the MP8I inte¬ 
grates up to eight CPUs and up to 128 
Mwords of central memory on one chas¬ 
sis. The Y-MP systems sustain 1.5- to 
2.3-Gflops performance on “real work,” 
according to the company. 

The MP4E ranges in price from $5.5 
to $9.2 million, while the MP8E costs 
$15.3 to $23.7 million, and the MP8I is 


$9 to $16.3 million. 

Release 6.0 of the Unicos operating 
system for supercomputers features X 
Window System-based performance 
analysis and application development 
tools that let users visualize and interpret 
data to optimize code. 

The new version features an enhanced 
scientific library that includes automatic 
parallel processing and supports OSI and 
Posix standards. 

Unicos 6.0 also includes a high-perfor¬ 
mance network storage management sys¬ 
tem that provides high-speed access to 
many files on various storage media. 
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Based on the Intel 80486 processing 
chip, the 486-25 and 486-33 machines 
come with 64 Kbytes of 95 percent hit- 
rate cache memory. They run at Land¬ 
mark VI.14 speeds of 114.1 and 151.9, 
respectively, according to the company. 

The standard configuration includes 
4-Mbytes of RAM (expandable to 8 
Mbytes), 3.5-in. and 5.25-in. floppy 
drives, and a 125-Mbyte hard drive (ex¬ 
pandable to 200 Mbytes). 

Both systems come with a 14-in. 
1,024 x 786 dot pitch VGA color moni¬ 
tor and a 16-bit, 512-Kbyte VGA adapt¬ 
er (expandable to 1 Mbyte). MS-DOS 
3.3 or 4.01 is included. 
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PC features 386SX compatibility 


The Sanyo MBC-18NB offers 32-bit 
processing in a notebook-sized machine 
with a 10-in. side-lit LCD display that 
features VGA resolution and a one-to- 
one aspect ratio. 

The PC offers a built-in 3.5-in. 1.44- 
Mbyte drive and a 2.5-in. 20-Mbyte hard 
drive with a 23-ms access time. 

Standard features include a detachable 
battery that provides up to three hours of 
use and an internal intelligent charger 
that restores battery power in one hour 
when the computer is idle. 


The MBC-18NB comes with a 16- 
MHz 80386SX CPU, 1 Mbyte of RAM 
(expandable to 5 Mbytes), a socket for a 
math coprocessor, and a 15-pin VGA ex¬ 
ternal video port. 

MS-DOS 4.01 comes with the hard 
drive and floppy disk. Options include an 
internal 2,400-baud modem, a 2-Mbyte 
RAM expansion card, and an external 
battery charger. 

The notebook PC costs $3,495. 
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VAX 9000s run Ultrix 

Version 4.2 of DEC’S Ultrix operating 
system and Worksystem Software pro¬ 
vides enhanced features for workstations 
and support for VAX 9000 Models 210, 
410, and 420. 

A multiscreen feature lets users dis¬ 
play information windows on more than 
one monitor with a single keyboard and 
mouse. 

Adobe Systems’ Display Postscript 
WYSIWYG software provides the same 
font-rendering technology found in the 
Adobe Type Manager. The Bookreader 
graphical on-line documentation tool 
provides indexing and illustrations, and 
quickly accesses topics and cross-refer¬ 
ences. Bookreader works with the Ultrix 
On-Line Documentation Library CD- 
ROM. 

The Ultrix release contains SQL Ver¬ 
sion 2 database software that complies 
with the ANSI standard. 

A two-user software license is avail¬ 
able with a system purchase. DECstation 
workstation and DECsystem computer 
upgrade licenses range from $1,180 to 
$20,980. The company plans a May 22 
delivery. 



The 6.9-lb. Sanyo unit extends XT-compatible line of notebook models. Reader Service 38 
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VAX fault-tolerant systems 


Digital Equipment Corp.’s VAX FT 
Model 110 features a custom-built plat¬ 
form for mission-critical applications 
that require fault tolerance for a low user 
demand. It offers 2.4 VAX units of per¬ 
formance and 6 transactions-per-second 
and supports up to 96 Mbytes of internal 
memory and up to 4 Gbytes of disk stor¬ 
age. 

Model 410 offers 6 VUPs and 16 TPS 
in server and multiuser configurations. 


The system supports up to 128 Mbytes of 
internal memory and 12 Gbytes of disk 
storage. 

Model 610 features the same power as 
the 410 version but supports up to twice 
as much on-line storage. The 612 model 
incorporates two Model 610s into a VAX 
cluster system, which increases perfor¬ 
mance to 12 VUPs and 26 TPS. 

Model 110, now available, varies in 
cost by configuration. Other models will 


ship the third quarter of 1991. 

Model 410 costs $145,077 for a mini¬ 
mum server; a fully configured, multius¬ 
er system costs $550,000. Model 610 
costs $164,875 for a minimum system 
and $750,000 for a multiuser system. 
Model 612 costs $275,567 for a mini¬ 
mum server configuration and $1 million 
for a multiuser system. 
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HP delivers RISC workstations 


Hewlett-Packard has announced a new 
family of workstations based on its RISC 
Precision Architecture (PA-RISC). The 
top-end desktop and deskside models re¬ 
putedly turn in performances at up to 76 
MIPS and 72.2 Specmarks. 

The 50-MHz entry-level Model 720 
desktop delivers 57 MIPS, 55.5 Spec- 
marks, and 17 Mflops. Model 730 has 
been clocked at 66 MHz, 76 MIPS, 72.2 
Specmarks, and 22 Mflops, which the 
company claims outperforms other work¬ 
stations in a similar price range. The 730 
gray-scale configuration includes 16 
Mbytes of memory, a 19-in. monitor, and 
a 210-Mbyte disk drive. 


Each desktop model sports 128-Kbyte 
instruction and 256-Kbyte data caches 
and supports up to 64 Mbytes of ECC 
RAM, 840 Mbytes of internal storage, 
and 10 Gbytes of total disk capacity. 
Server configurations include one 400- 
Mbyte (Model 720) or two 400-Mbyte 
(Model 730) varieties. 

The Model 750 deskside operates like 
a 730 and has a 512-Kbyte cache, 192 
Mbytes of ECC RAM, 2.6 Gbytes of in¬ 
ternal storage, and 40 Gbytes of total 
disk capacity. CRX color graphics in¬ 
cludes 16 Mbytes of memory, a 19-in. 
monitor, and a 660-Mbyte disk. Servers 
have a 660-Mbyte disk drive. 


The Series 700 machines implement 
the EISA bus and SCSI-II, Ethernet, RS- 
232, Centronics, and HP-HIL ports. GRX 
and CRX graphics support more than 1 
million 2D or 3D vectors per second. Re¬ 
lease 8.0 of the HP-UX operating system 
complies with X/Open, Posix, and 
SVID2 interface specifications. 

The desktop 720 starts at $11,990, and 
the 730 at $19,980. Servers are $15,990 
and $23,990. The base configuration of 
the Model 750 costs $43,190, while the 
server starts at $39,690. 
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The Series 700 HP workstations support new graphics options integrated closely with the PA-RISC architecture. 
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A new C programming tool 


The Rule-Extended Algorithmic Lan¬ 
guage (Ral) from Production Systems 
Technologies lets users incorporate both 
rules and objects into C programs. 

Users write Ral programs primarily in 
C, with Ral declarations and statements 
interspersed. The Ral preprocessor trans¬ 
lates the extensions into standard C code. 

C libraries for interfacing to database 
management systems and displaying 


Low-cost notebook PCs 

Desk Master 286/12 and 386S/16 from 
Samsung Information Systems America 
include a built-in hard-disk interface, a 
floppy-disk controller, and a VGA con¬ 
troller. 

The 286/12 contains 1 Mbyte of RAM 
(expandable to 2 Mbytes) and a 5.25-in. 

1.2-Mbyte floppy-disk drive. The system 
features three 16-bit expansion slots, and 
various ports, including parallel, serial, 
mouse, and analog VGA. 


CASE for OS/2 

Cognos’s Power Case for OS/2 aids 
analysis and design and automates the 
code generation, documentation, and 
maintenance of large business applica¬ 
tions for midrange computers. These in¬ 
clude Hewlett-Packard, IBM, Digital, 
and Data General, for both proprietary 
and Unix-based systems. 


Network intelligence and 
connectivity featured 

QMS Inc. introduces the QMS-PS 
printer for high-volume laser printing in 
applications such as corporate depart¬ 
ments. 

Based on a MIPS R3000 RISC internal 
controller with 8 Mbytes of RAM, the 
printer accommodates simultaneously ac¬ 
tive serial, parallel, and Ethernet inter¬ 
faces for direct network connectivity. 
Automatic emulation switching and an 
expanded collection of resident typefaces 
come standard. 

Supported computer platforms include 
DEC, IBM, Macintosh, and Unix sys- 

The printer costs $15,995. A duplex¬ 
ing and high-capacity 1,000-sheet feeder 
option is available for $3,495. 
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graphics can be used in Ral programs. 

Versions for PCs and Sun-3, Sparcsta- 
tions, and DECstations are available. On 
the PC, a Microsoft C compiler version 
6.0 or later and MS-DOS version 3.0 or 
later or OS/2 are required. 

Prices for Ral start at $849 on the PC. 
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The 386S/16 version features a 16- 
MHz 80386SX microprocessor, 2 
Mbytes of RAM (expandable to 8 
Mbytes), and a 3.5-in. 1.44-Mbyte flop¬ 
py-disk drive. An internal 3.4-in. half¬ 
height disk-drive bay and an external 
5.25-in. half-height bay are included. 

Desk Master 286/12 costs $1,099, and 
Desk Master 386/16 costs $1,599. 
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Power Case is fully integrated within a 
a fourth-generation language (4GL) envi¬ 
ronment and ANSI-standard SQL rela¬ 
tional databases. The tool also supports 
proprietary file structures. 

The initial license costs $15,000. 
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QMS laser printer features 20-page-per- 
minute speed for 40 to 50 users. 


Critical on-line computers 

Stratus introduced a number of sys¬ 
tems for distributed critical on-line com¬ 
puting applications. 

The XA/R Model 20 is a fault-tolerant 
RISC system based on the Intel i860. 

The midrange computer runs on the Unix 
System V Release 4 and the Stratus VOS 
operating systems. 

The FTX Release 2 is a Unix-based 
operating system that lets users run stan¬ 
dard Unix applications without interrup¬ 
tion or degradation, even during a com¬ 
ponent failure or repairs. 

The Stratus Intelligent Network Appli¬ 
cations Platform (SINAP) for the tele¬ 
communications market runs on the FTX 
operating system. 

Two additional systems include Mod¬ 
els 270 and 280, high-end multiprocessor 
machines for very high volume critical 
on-line processing. 

The XA/R Model 20 starts at $247,000 
for FTX systems and $275,000 for VOS 
systems. FTX Release 2 is included in 
the Model 20 base price. SINAP soft¬ 
ware starts at $85,000. Model 270 starts 
at $1,266,000, and Model 280 starts at 
$1,411,000. 
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System/6000 series 
adds models 

IBM has produced two new RISC 
desktop systems and a rack-mounted 
server, along with storage systems that 
support the workstations. 

The 25-MHz Powerstation/Powerserv- 
er 320H provides a performance of 11.7 
Mflops and 32.4 Specmarks. The sys¬ 
tems come with 16 Mbytes of system 
memory and a 160-Mbyte hard disk, ex¬ 
pandable to 800 Mbytes via two SCSI 
disk drives. 

The rack-mounted 41-MHz Pow- 
erserver 950 features ratings of 25 
Mflops and 56.3 Specmarks. Fixed disks 
can expand to 11.9 Gbytes. 

The Model 500 Deskside Expansion 
Unit provides additional storage capacity 
of up to 3.4 Gbytes to the series. The 
Model 010 Drawer Expansion Unit and 
Expansion Rack provides up to 22.2 
Gbytes of disk storage. 

The 320H starts at $20,500, the 950 at 
under $165,000, the expansion unit at 
$10,400, and the rack at $5,500 (the last 
two will ship in September). 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


Analog Devices 
DAC-8840/8841 


j Analog Devices 

' SSM-2125 

Sound decoder 


Fujitsu 

MB88346 

DAC 


Gould AMI 
PA7040 

CMOS PEEL array 


Logical Solutions 

Technology 

LT54/74TC32x/ 

LT54/74TV32x 

Circuits 

LSI Logic 
Verilog-XL 
Design Kit 


Microchip Technology 

27HC1616 

EPROM 


Microchip Technology 

93C56/93C66 

EEPROM 


Sharp 

SRAM 

LH521008/ 

LH521002 


Texas Instruments 

TLC1225 

ADC 


Unitrod Integrated 

Circuits 

UC3724/3725 


Eight-bit octal multiplying DACs replace mechanical potentiometers for automatic micro- 120 

processor adjustments of AC/DC voltage gain. The 8840 operates from ±5 V supply and 
accepts bipolar ±3 V reference inputs with four-quadrant multiplication. The 8841 requires a 5 V 
supply, accepts unipolar 0 to 1.5 V input, and works with two-quadrant multiplication. Operate 
in - 40° to85°C. Come in 24-pin plastic and ceramic DIPs and 24-lead SOICs. Cost (100s): From 
$9.95. 

Dolby surround-sound decoder integrates an autobalance function and combines core functions 121 

of a complete Prologic system on one chip. Autobalance replaces discrete circuit with 24 active 
and passive components. Operates in the - 20° to 80° C temperature range. Runs from single 
12- to 16 V or dual ±6 to +8 V supplies. Comes in 48-pin plastic DIP. Cost (100s): 

From $15. 

Operates with 4- and 8-bit microcontrollers at a minimum rate of 2.5 MHz. Individual channel 122 

units serially input digital data. DAC converts data into 12 monotonic 8-bit analog outputs for 
better precision in graphic and control applications. Combines CMOS technology and bipolar capa¬ 
bilities. Requires 5 V power supply, consumes up to 250 mW power, and functions in the temperature 
range of - 20° to 85 °C. Comes in 20-pin plastic DIP and 20-pin SOJ plastic flatpack. Cost (1,000s): 

$4.50. 

Programmable electrically erasable logic array enables users to implement multilevel, I/O 123 

buried logic functions in high-density PCB designs. Operates with a single-level delay as fast 
as 13 ns (internal) and at clock rates greater than 50 MHz. Comes in 40-pin 600-mil DIP and 
44-pin PLCC. Cost (1,000s): $22. 

Two 32-bit circuits control (LT54/74TC32x) and observe (LT54/74TV32x) multichip 124 

module internal nodes. Come as die that can incorporate into MCMs for test generation and fault 
isolation. Function as 16- or 32-bit shift registers, addressable latches, and multiplexers and 
decoders. Available in commercial or military version. No price given. 


Provides simulation libraries and interfaces between the Verilog-XL simulation environment 125 

and LSI Logic modular design environment tools. Supports silicon technology verification, sim¬ 
ulation, and analysis. Operates with Verilog-XL version 1.5c on Sun 3/4 workstations. Cost: 

From $ 10,000 (varies with configuration, quantity, and number of libraries). 

Device features 16K x 16 high-speed CMOS EPROM and comes in 45-, 55-, 70-, and 90-ns 126 

speeds, with a 40-ns version available in June. Meets no-wait-state performance requirements for 
16- and 32-bit microprocessors without external buffers. Various packages available. Cost 
(1,000s): From $7.41 (90 ns) to $ 10.92 (45 ns). 

Three-wire serial EEPROMs come in 2K (93C56) and 4K (93C66) densities and feature a 127 

sequential function that enables reading the entire memory array in one instruction. Pack¬ 
aged in 8-lead PDIP and 8- or 14-lead SOIC. Options include preprogramming and tape and reel 
carriers. Cost (1,000s, PDIP): $ 1.40 ( 93C56); $ 1.70 (93C66). 

Two 1-MbitSRAMS,the 128Kx8LH521008andthe256Kx4LH521002, feature 25-and 128 

35-ns access times. Come in 32-pin, 400-mil SOJ (LH521008) and 28-pin, 400-mil SOJ with 
output enable function. Cost (1,000s): $60.32, LH521002K-35; $79.37, LH521002K-25; $63.49, 
LH521008K-35; $85.25, LH521008K-25. 

Differential inputs reduce system error created by common-mode noise. Compatible with most 129 


microprocessors and digital signal processors. Features 85-mW maximum power requirement, 

12-bit integral linearity, and 12-bits-plus-sign resolution. Comes in plastic DIP for the 
-40°to85°C temperature range. Cost (1,000s): $16.74 (TLC1225). 

Function as a high-side field effect transistor driver pair. Implement a circuit in which a pulse 130 

transformer isolates the high-side driver IC from the control IC. Come in 8-pin DIL ceramic (J) for 
military or plastic (N) for commercial use. Cost (1,000s): $ 1.75, UC3724N isolated transmitter or 
UC3725 isolated driver device. 
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Microsystem Announcements 


Company, Model, Function Comments R.S. No. 


Bit 3 

Model 477 
VME adapter 


Bristol Research 
BRC-9100 

Cell controller system 


Datem 
DDCM2240 
Interface module 


Digital Vision 
Computer Eyes/Pro 
Video digitizer for Mac 


Interphase 
NC400 Network 
Coprocessor 
Ethernet controller 

Memrel 
Parity +Plus 
Memory boards 

Microtech 

Eclipse series 

Next memory products 


Retco Sales 
Super VGA board 


Sonitech International 
Spirit-30 

DSP board for S Bus 


Trackmate America 
Generation 3.0 
Cleaning/diagnostic 
system 

Vector Electronic 
Model 4619-6-10 
32-bit backplane 


V ermont Microsystems 
Animator/Shader 
3D graphics controllers 


Connects VMEbus system with an IBM RISC System/6000 via a tightly coupled memory- 135 

mapped interface. Supports random-access bus mastering from either system and supports 32-bit 
data streaming with a DMA controller. Comes with two cards interconnected with a shielded cable. 

Cost: $3,995. 

Designed for mounting in a 19-in. rack, rugged 386-based system features capacity for up 136 

to six half-height floppy or hard disk drives. Communicates directly with data acquisition 
devices within the system. Comes with 25-MHz motherboard, 40-Mbyte hard disk, and a 
1.2- or 1.44-Mbyte floppy drive. Cost: $5,370. 

SCSI bus to Bitbus II interface module measures 100 x 160 mm and comes in a plastic shell for 137 

desktop mounting. Based on the 80C152 microprocessor, comes configured with 32-Kbyte RAM 
and 32-Kbyte EPROM. Supports message sizes up to 256 bytes, features an improved remote 
access and control task, and switches mastership on the network. Cost: $ 1,995. 

Full-color Macintosh II version accepts PAL and SECAM video and captures images from any 138 

standard video source with resolutions to 640 x 480 pixels at 24 bits per pixel. Requires an 8- or 
24-bit display and at least 2 Mbytes of RAM. Saves images in PICT, PICT2, TIFF, and Mac 
Paint formats. Cost: $499.95. 

Jointly marketed by Sun Microsystems and Interphase, the controller consists of a VMEbus board 139 

and network protocol processing software. Offloads protocol processing and increases throughput 
and application performance on the server. Comes in Sparcserver470/490 configurations. 

Cost: $7,950 (current Sparcserver users). 

Add-in boards for IBM PC AT/compatibles in stand-alone or network applications feature built- 140 

in error detection and correction for memory-intensive programs. ED AC technology protects 
against soft-error shutdowns that require system reboot. No price given. 

Include external drives of200,320,400, and 650 Mbytes and 1 Gbyte, with access times 141 


as low as 16 ms. The 50R removable hard drive features 50-Mbyte removable cartridges, and the 
CD ROM drive offers a 350-ms access time. Memory upgrade kits of 1 and 4 Mbytes are available. 

Cost: $ 1,099 (CD ROM); $ 1,399 (removable hard drive); $ 1,899 to $5,399 (external hard drives). 

Hybrid of Speed Star super VGA board and Edsun Laboratories Continuous Edge Graphics allows 142 

regular VGA monitors to display 2,048 x 1,536 virtual resolution with up to 790,000 simultaneous 
colors. Drivers are available for Auto CAD 10/11, Lotus 1-2-3, Symphony, and Windows 3.0. 

Comes with 1 Mbyte of RAM and a Panacea display list processor. Cost: $449. 

Digital signal processing board runs at 33 Mflops. Based on Texas Instruments TMS320C30, 143 

board works with computation-intensive applications. Transfers data at up to 25 Mbytes/sec., 
features 256 Kbytes to 2 Mbytes of zero-wait-state static RAM, and provides 32 Kbyte SRAM 
on the expansion bus. Provides two high-speed parallel ports and two 8-bit serial ports. Cost: 

$3,995 (256 Kbytes SRAM). 

Menu-driven system (in English, French, and Spanish) detects dirt on floppy disks and recommends 144 
the length of the cleaning program. Software manages the cleaning process. All diagnostic results 
are saved in a report by date for each drive. Works with 3.5-in. or 5.25-in. floppy disk drives for IBM 
PC AT or PS/2 and Apple Macintosh. Cost: Ranges from $34.95 to $44.95, depending on model. 

Multilayer 10-slot passive backplane accepts EISA, PC AT/XT, or PC add-in cards in any 145 

arrangement. Facilitates integration of EISA boards from manufacturers performing various 
functions at different operating speeds. Filtered power input includes ±5 V and ± 12V, and 
user-selectable termination connects to 5 V and ground. Cost: $450. 

Single-slotPC controllers feature l,280x 1,024 resolution, a graphics processor, a 25-Mflops 146 

math booster, and a 16-bit Z-buffer for real-time display of complex 3D images. The Animator also 
features a second full-color screen buffer and overlay plane. Controllers calculate and display the 3D 
image for the system. Cost: $5,995, Shader (X series, Model 3D-S); $6,995, Animator (X series 
Model 3D-A). 
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28 th ACM/IEEE 

DESIGN AUTOMATION CONFERENCE and EXHIBITION 

FROM GATE ARRAYS TO THE GOLDEN GATE 


• Over 125 exhibitors of CAD 
hardware and software products. 

• Over 60 exhibitor technical 
presentations Monday, 

June 17, 1991, many 
announcing new products. 

•Monday Exhibits Only Passes. 

Free invitations available 
from 
or cal 


n participating companies 
:all toll free, 1-800-321-4573 



DA Professionals world-wide 
attend DAC to keep current 
with advancements 
in Design Automation. 

• Seven full day tutorials 
Friday, June 21, 1991. 

• Over 140 papers, tutorials 
and panel presentations. 
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ADVANCE REGISTRATION ENDS MAY 17, 1991. 


MOSCONE CENTER 

June 17-21, 1991 
San Francisco, California 


ATTEND THE WORLD’S 
LARGEST DESIGN AUTOMATION EVENT 

This year's conference starts Monday, June 17,1991 !! 


HOTEL RESERVATION FORM 
28th Design Automation Conference 
June 17-21,1991 




ADVANCE REGISTRATION FORM 
28th Design Automation Conference 
June 17-21,1991 
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CONFERENCES 


Five plenary addresses highlight Compcon Spring 91 


Ware Myers , Contributing Editor 

GaAs targets 100-MHz-plus 
computers 

Five years ago, a gallium arsenide in¬ 
tegrated circuit contained three or four 
hundred transistors, a few dozen gates, 
and a few input/output connections. It 
was used only in very high-speed appli¬ 
cations, fundamentally because electrons 
move two to four times faster through 
gallium arsenide crystal lattice than 
through silicon crystal. 

Today, a typical gallium arsenide pro¬ 
duction IC may have 125,000 transistors, 
30,000 gates, and 256 I/O connections. A 
350,000-transistor device is expected to 
be in production by the end of this year. 
A one-million transistor device will be 
prototyped this summer. A gallium ar¬ 
senide microprocessor will appear soon. 
Though still used where extreme high 
speed is essential, gallium arsenide is 
finding increased markets at lower fre¬ 
quency levels — 100 megahertz — in the 
computer industry. 

Such was the view of the GaAs digital 
IC offered by Lou Tomasetta, president 
of Vitesse Semiconductor, Camarillo, 
California, at the February 26 opening 
plenary session of Compcon Spring 91, 
the 36th IEEE Computer Society Interna¬ 
tional Conference. As usual, the week- 
long event was held at the Cathedral Hill 
Hotel in San Francisco. 

The old bromide that “GaAs is the 
semiconductor of the future and always 
will be” no longer holds. “The situation 
has changed,” Tomasetta said, “particu¬ 
larly in the last five or six years. The 
market is no longer limited to the speed- 
at-any-price user.” 

Here’s the way he sees the world of 
semiconductors shaping up. CMOS 
(complementary metal oxide silicon) is 
the dominant technology, as Figure 1 
shows. The density of Bipolar CMOS is 
growing rapidly. GaAs is coming on 
strongly. ECL (emitter-coupled logic) 
will be disappearing from very large- 
scale ICs over the next five years. 

“By 1995, the world of semiconduc¬ 
tors for high-performance computing or 
for computers in general will have 
CMOS at the base, solving problems up 
to 60 or 70 MHz, BiCMOS from 60 to 



Today, logic designers can look for 
paths where the overall speed of the 
product is limited by the speed of a 


particular circuit and substitute a fast 
GaAs part for a slower silicon part, 
advised Lou Tomasetta, president of 
Vitesse Semiconductor. 


100 MHz, and GaAs for 100 MHz and 
greater,” Tomasetta said. All these tech¬ 
nologies will sit on the same price-per¬ 
formance curve. They will not necessari¬ 


ly compete very hard with each other. If 
you want to design a 50-MHz machine, 
you won’t have to pay for BiCMOS or 
GaAs. You would use GaAs only when 
you want 100 MHz or more. 

“The only way you can achieve that 
speed is with GaAs,” he said. “So the fu¬ 
ture is with GaAs.” 

What has happened in recent years to 
bring GaAs to this take-off position? Es¬ 
sentially three things, Tomasetta out¬ 
lined. Gallium arsenide materials have 
improved; GaAs process technology has 
hitched onto silicon process technology; 
and larger wafers and higher yields have 
reduced cost. 

“Most of the material problems you 
have heard about in the last 10 years — 
the material being brittle, unstable, non- 
uniform — quite frankly were red her¬ 
rings,” Tomasetta asserted. “The prob¬ 
lems really lay in the process technolo¬ 
gies that people were using then. The 
processes were so unstable that you 
couldn’t reproduce results.” 

In the mid-1980s, GaAs device fabri¬ 
cators discovered that they could suc¬ 
cessfully carry over to their process 
much of the know-how of silicon process 
technology. They began to use the stan¬ 
dard process equipment of the silicon 
semiconductor industry. They focused 


1M 



Year 


Figure 1. The chip densities of the principal technologies have been increasing 
rapidly, but GaAs from a very low level in 1986 will be within a factor of two of 
CMOS and BiCMOS in a year or two. (Data courtesy of Vitesse Semiconductor.) 
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not so much on device speed, but on pro¬ 
cess control and yield. Achieving maxi¬ 
mum speed was less important in the 
computer marketplace than in the tradi¬ 
tional GaAs applications, such as micro- 
wave communications. Tomasetta esti¬ 
mated that the computer industry 
represents between 65 and 80 percent of 
the volume of the semiconductor indus¬ 
try. To build up volume, GaAs producers 
had to attack the computer marketplace. 

“I venture to assert that most of you 
think that gallium arsenide technology is 
much more complicated than silicon 
MOS technology,” Tomasetta went on. 
“In fact, the reverse is true. The GaAs 
process has only 11 mask levels.” 

Ten years ago, the standard GaAs wa¬ 
fer was one inch on a side. “Today, you 
can buy four-inch wafers in high volume 
that run on conventional processing 
equipment,” he said. “Five-inch wafers 
are certainly technologically feasible. 
Six-inch wafers are probably possible.” 

Wafer size is important in getting the 
cost down, because a four-inch wafer 
carries four times as many dies as a two- 
inch wafer. Ultimately price depends 
upon wafer size and yield. 

Computers, of course, are following a 
demanding price-performance curve of 
their own. “You have to double the per¬ 
formance of your machine at the same 
price every two or three years,” Tomaset¬ 
ta told the computer designers in the au¬ 
dience. For the chip maker, operating in 
this fast-moving market means that he 
has to achieve higher integration levels 
at a rapid pace, double speed every three 
or four years, and decrease power con¬ 
sumption. 

“No one of these improvements hap¬ 



Compcon Spring 91 featured speakers 
on five topics pertaining to various as¬ 
pects of the future at its three plenary 
sessions, General Chair Roger E. 
Anderson, Lawrence Livermore Na¬ 
tional Laboratory, pointed out in 
opening the conference February 26. 


pens fast enough to double computer per¬ 
formance every two or three years,” he 
noted. “You have to do all three — in¬ 
crease speed and complexity and de¬ 
crease power.” 

GaAs is going to be successful in the 
computer marketplace, Tomasetta said, 
because it is faster, has greater complexi¬ 
ty or density, consumes less power, and 
is simpler to manufacture. 

Twenty-year goals guide 
next steps 

“It is sometimes said that the purpose 
of a five-year plan is not to tell you 
where you will be in five years, but to 
tell you what you should be doing to¬ 
day,” Eric Drexler, president of the Fore¬ 
sight Institute, said, addressing the sec¬ 
ond Compcon plenary session. The 
Foresight Institute tries to look ahead a 
generation or so. “The purpose of defin¬ 
ing 20-year objectives is not to tell you 
what you are going to be doing in 20 
years; it is to set a better five-year plan.” 

Drexler stressed that he is not predict¬ 
ing the future. He is trying to indicate the 
characteristics of systems that may be 
possible — in terms of the underlying 
laws of physics and chemistry — in the 
distant future. “By the time you have 
been working toward these goals for 10 
years, you will have a much better idea 
of what the future system will be like 
than any idea you could have today,” he 
pointed out. 

All the physically possible technolo¬ 
gies might be thought of as occupying 
the large area in Figure 2, Drexler ob¬ 
served. Within that bound, at any given 



The featured speakers each morning 
led into four parallel tracks of papers 
and panels on a broad base of comput¬ 
er-related subjects organized by Pro¬ 
gram Co-chairs Creve Maples, Sandia 
National Laboratory, and Michelle 
Aden (not shown), Sun Microsystems. 



Eric Drexler, president of the Fore¬ 


sight Institute and a visiting scholar at 
Stanford University, believes that 
looking ahead 20 years, even if the 
view that far out is misty, gives us 
clues to the research directions we 
should be following now. 


time, we understand only the technolo¬ 
gies within the small area at the right. At 
this same time, we can actually make 
only the systems that are manufacturable 
— the left-hand area. Thus, there are 
areas where we have some understanding 
of the potential technologies, but not yet 
enough to actually manufacture some¬ 
thing utilizing them. 

Drexler believes that computing power 
of 10 15 million instructions per second is 
possible when we have achieved suffi¬ 
cient understanding of behavior on the 
molecular level to build it. As a first 
step, he asked the audience to imagine a 
cubic nanometer. To get an idea of where 



Figure 2. Of all the technologies that 
may exist in the universe, we under¬ 
stand and can manufacture only a 
small fraction. By peering into the out¬ 
er edges of these overlapping areas, we 
can achieve glimpses of what the fu¬ 
ture may hold for us. 
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this tiny volume is on the scale of the 
universe, we have to multiply one of the 
edges of that cube by 1,000 to get up to 
one micron (micrometer). At the one-mi¬ 
cron level, we are in the range of the 
channel length of current integrated tran¬ 
sistor technology. 

So one cubic nanometer is diminutive, 
but it still contains more than 100 mole¬ 
cules. To Drexler a molecule is a poten¬ 
tially designable element. He imagined a 
rod of molecular dimensions that would 
move under the influence of some force 
from one position to another, represent¬ 
ing on-off positions. 

Thus, we would have a switch and 
could go from there to a NAND gate, and 
thence to a register and the other artifacts 
of digital logic. A physical object this 
small could move very fast. Switching 
time might be in picoseconds. One could 
think of this movement as similar to vi¬ 
bration. Being so small, it would take lit¬ 
tle energy to move it, so there would be 
little heat to dissipate. If billions and bil¬ 
lions of these elements were packed into 
one small box, of course, those tiny bits 
of energy might add up to a dissipation 
problem. 

Drexler noted that the power dissipa¬ 
tion per state change had been steadily 
dropping during the integrated-circuit pe¬ 
riod. If the trend continues, the dissipa¬ 
tion per state change would be down to 
one electron dropping through one volt 
by the year 2005. 

If one hypothesizes a cube 10 nanome¬ 
ters on a side per on-off element, one cu¬ 
bic centimeter would contain 10 18 
switches. Then, if one assumes that each 
switch changes state on the average once 
each millisecond and uses one electron 
volt of energy to do so, the cube would 
have to dissipate some 160 watts. How¬ 
ever, one electron volt is a very minute 
energy unit (1.6 x 10" 19 joule). If we as¬ 
sume a larger switching energy, say one 
nanowatt per switching element (still 
sounds very small), the energy dissipa¬ 
tion of the cube would amount to 1,000 
megawatts, an amount of power that 
would drain a large power plant. Drexler 
hasn’t worked out the details yet. 

He concluded that “the long-term po¬ 
tential of molecular manufacturing, 
which includes 10 15 MIPS computers, is 
clearly enormous.” Steps toward this 
goal can be taken today at low cost. 
Computers capable of 10 15 MIPS are not 
around the corner, he admitted, but steps 
toward that goal will yield knowledge 
that will pay off along the way. In fact, 
various laboratories in the United States 
are working in this area. Japanese inter¬ 
est in nanotechnology is being financed, 
still on a small scale, by the Ministry of 
International Trade and Industry. 


Multimedia is more than 
digital video 

“These days, in many people’s minds, 
the term ‘multimedia’ is equated with 
digital video,” observed Andy Lippman, 
associate director of the Media Laborato¬ 
ry at the Massachusetts Institute of Tech¬ 
nology, in the third plenary address. 
“That is not all it is — it is a major 



our Droaacast systems merge with 
our computer systems in some kind of 
next-generation high-definition televi¬ 
sion multimedia, we need creative in¬ 
vention, as well as technical invention, 
said Andy Lippman, associate director 
of the MIT Media Lab. 


threshold that we are approaching rapid¬ 
ly. Like all revolutions, we are facing the 
danger of doing it utterly wrong and hav¬ 
ing to do it over again.” 

Lippman pointed out that the world 
has already done high-definition televi¬ 
sion wrong once. This wrong try was 
based on simple analog extensions of ex¬ 
isting TV. Sets based on this concept are 
on sale in Japan for $39,000 and will be 
down to perhaps $4,000 in a few years. 

“The canonical definition of HDTV, as 
everyone knows, is a television picture 
that is somewhat wider and has twice as 
many lines as current pictures,” he said. 
“On some future date, perhaps December 
24, 1994, someone comes down the 
chimney, takes a new HDTV set out of 
his bag, puts it on your table, takes your 
old set, and escapes up the chimney. In 
the morning, nothing in your life is dif¬ 
ferent — except your television picture 
is a little bit clearer and your bank ac¬ 
count has been debited some $4,000.” 

This model of HDTV troubles Lipp¬ 
man. When you ask the average person 
what is wrong with TV, he explained. 


very few say that the picture quality is 
not good enough. 

Now, the world is gearing up to do 
HDTV wrong the second time, he contin¬ 
ued. This second generation is digital 
television. The Europeans are about to 
revise their Eureka 95 HDTV project 
from analog to digital. The US Federal 
Communications Commission is running 
“a bake-off to decide how we should 
broadcast advanced television in Ameri¬ 
ca.” All the US entrants are now propos¬ 
ing digital systems. 

“I sincerely hope this winner-take-all 
contest will never come to pass,” Lipp¬ 
man argued. “The danger is that people 
will focus solely on the efficiency of the 
digital transmission.” He favors a more 
ambitious yardstick. 

One element of his multidimensional 
yardstick is “some sort of sensitivity to 
the creative and cognitive aspects” of 
communication with human beings. He 
quoted Jerome Weisner, once president 
of MIT and science advisor to President 
John F. Kennedy, as saying: “We seem 
to make simultaneous and parallel 
progress in understanding communica¬ 
tions systems electronically at the same 
time that we make progress in under¬ 
standing them biologically.” 

Secondly, effective communication is 
not just video, whether it is analog or 
digital. It encompasses sound as well. 

Beyond these two broad objectives, he 
listed five simple attributes of a digital 
moving picture that have a bearing on the 
design of a multimedia-HDTV system: 

(1) Digital video bits exist outside the 
strictures of television broadcasting stan¬ 
dards. Once a system designer has a pic¬ 
ture in digital form, he or she can manip¬ 
ulate the bits so that the picture can be 
rendered on any system in any size. 

(2) Digital video is independent of 
broadcast channel standards. Once you 
have transformed a picture into bits, you 
can send it over telephone lines, fiber op¬ 
tics, or satellites; you don’t have to send 
it over a standardized TV channel. 

(3) Digital video is independent of 
time. You can send it in real time, more 
than real time, or less than real time. 

(4) A digital representation can be in¬ 
dependent of quality. The quality of 
present TV signals is limited by channel 
bandwidth. “There is only so much you 
can do in your home to make the picture 
better — and it is not very much,” said 
Lippman. 

(5) With digital representation, you 
can break the boundary of the frame. The 
primitive element is no longer the whole 
picture; it can become an element inside 
the picture. Lippman calls it “intraframe 
interaction.” He considers it “most inter¬ 
esting,” but also “most speculative, be- 
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cause we don’t know how to do it. Even 
if we did know how to do it, we don’t 
know what to do with it. A certain 
amount of technical invention — and a 
certain amount of creative invention — 
is necessary to realize the goal of in¬ 
traframe interaction.” 

As an example, he described an exper¬ 
iment in which the Media Lab, working 
from old “I Love Lucy” episodes, pieced 
together a representation of Lucy’s kitch¬ 
en set, never seen in its entirety in any 
one frame. The experimenters deleted the 
moving actors from the kitchen represen¬ 
tation, leaving a plan from which the Lab 
rebuilt the entire set. 

Lucy’s kitchen is an example of one of 
the capabilities people may want in a 
multimedia-HDTV system: the ability to 
interact with it. For instance, you might 
like to call up a musician and play a duet 
with him or her. Moreover, you might 
like to make the musician pause while 
you study your score more intently. You 
might like to slow down the musician’s 
tempo when you can’t keep up the pro¬ 
fessional pace. 

One of the great shortages in high- 
technology societies is clock time. So, a 
busy executive might like a computer 
that can monitor a business news channel 
all day, beep when an item in the execu¬ 
tive’s sphere appears, then play it back 
on command. At home, the unit might 
monitor the general news channels all 
day and play back 15 minutes of individ¬ 
ually focused news when the executive 
gets home. Or, in an extreme case, the 
unit might show tire commercials be¬ 
cause, communicating with the compara¬ 
ble unit in the executive’s car, it learned 
that the auto had a flat tire during the 
evening commute. 

Systems with capabilities on this level 
would even bypass the grand problem on 
which the world’s consumers are current¬ 
ly hung up: how to program their VCRs to 
record when they are out for the evening. 

The ultimate multimedia-plus-digital- 
HDTV system has to evolve in terms of 
these objectives and attributes toward 
meeting these kinds of needs, Lippman 
feels. In the meantime, intermediate sys¬ 
tems ideally should be designed to per¬ 
mit evolution to occur as we learn more 
about what communicating with human 
beings means and as the marketplace 
feeds back information on what they will 
happily use. 

Programming virtual 
reality 

If we could attach input devices to the 
human body that would replace our view 
of the world as being “out there,” we 


could achieve “virtual reality.” The input 
devices exist — goggles containing 
small monitors running computer graph¬ 
ics, earphones, and gloves for tactile 
feedback. When these devices are mount¬ 
ed directly on the body, like clothing, 
they can provide sensory impressions 
that mimic reality. In contrast, an indi¬ 
vidual in a movie theater or in his own 
living room watching television is entire¬ 
ly aware that he is watching a screen and 



“Right now the primary commercial 
application of virtual reality is in expe¬ 
riential design,” Jaron Lanier, chief 
executive officer of VPL Research, 
said. “In this application, we simulate 
a structure before it is actually built so 
that the architect — or anybody else 
designing something — can have the 
experience of walking through it.” 


that he is, himself, in the environment of 
the theater or his living room. 

If these devices are programmed to 
present some simple environment to the 
person wearing them, we have a tentative 
approach to “reality.” The person feels 
that he is immersed in a virtual environ¬ 
ment. At the present state of the hard¬ 
ware and software arts, the environment 
created is rather crude. The person wear¬ 
ing the apparatus must make a leap of 
faith toward'the state of “virtual reality.” 

Real-time simulation of visual, audito¬ 
ry, and tactile inputs takes a lot of com¬ 
puter power. Making it all work takes a 
lot of programming. The latter is the area 
in which Jaron Lanier, founder and CEO 
of VPL Research, shared his experience 
with the Compcon plenary audience. 

At the current state of the computer 
graphics art, generating a fairly realistic 
image with color, texture, light sources, 
shadows, etc. may take several minutes 


on a powerful computer. In the virtual re¬ 
ality world, the image would have to be 
dynamic, if it is to be virtually real. If it 
is to appear to be three dimensional, the 
view presented to each eye would have 
to be slightly different. 

Moving objects would have to be con¬ 
strained not to interpenetrate each other. 
When your gloved virtual hand places a 
virtual object on a virtual table, the ob¬ 
ject must rest there, not move down and 
out at the bottom of the environment. 
Hinged objects, such as the elbow or 
knee, would have to be constrained to the 
limited degrees of freedom they have in 
real life. 

“One of the merits of virtual reality is 
that it enables people to interact with 
large, complex systems and thus to under¬ 
stand them more easily,” Lanier said. “All 
of you know some large city well; you 
know how to get around in it. That knowl¬ 
edge is actually an incredibly complicated 
information structure. We evolved in this 
environment, so we have a very good ca¬ 
pability for getting around in it.” 

Therefore, if we can convert other 
large, complex problems into an array in 
space, comparable to the city layout, we 
find that people learn it much faster than 
they learn the same information present¬ 
ed in other forms, he continued. “People 
just learn faster when information is 
turned into an environment that they 
learn to navigate.” 

Another application of virtual reality is 
in training. It can be used to train work¬ 
ers to put together complex assemblies 
when the plans are ready, but the physi¬ 
cal parts do not yet exist. Another exam¬ 
ple is the display of complex informa¬ 
tion, such as the operational performance 
of large networks. “We’ll leave to your 
imagination a host of applications in en¬ 
tertainment,” he added. 

Microprocessor patent 
holder challenged 

In December 1970, Gilbert P. Hyatt 
filed an initial application for a patent on 
the microprocessor on a chip; last July, 
after 20 years of examination and 10,000 
pages of documentation, the Patent Of¬ 
fice awarded it to him. In his featured 
speech at Compcon, Hyatt looked ahead 
to future developments in personal com¬ 
puters. 

A month after the conference, howev¬ 
er, on April 2, 1991, the US Patent Of¬ 
fice decided to undertake an interference 
investigation on the basis of a January 
15, 1991, letter from Texas Instruments 
(see related story on p.85). At issue is 
whether Gary W. Boone, a former TI en¬ 
gineer, or Hyatt had been first on several 
important claims. 
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The company contends that Boone’s 
application, filed on July 19, 1971, pre¬ 
dates by many years Hyatt’s first set of 
adequate claims, not filed until Decem¬ 
ber 1977. 

Hyatt told the New York Times, “I 
have all the firsts and therefore I will 
prevail.” 

Meantime, at Compcon, Hyatt told the 
final plenary session: “For the past 15 
years, I have been heavily involved in 
exotic new technologies and they are get¬ 
ting close to being market-ready. I call 
them PC21, the personal computer for 
the 21st century. 

“It’s a radical departure from current 
personal computers,” he continued. 
“Computers are very primitive presently. 
Computer literacy is where the human has 
to be trained to interact with the comput¬ 
er. What isn’t easy to implement in the 
computer is what the operator has to 
learn. What I am working towards is hu¬ 
man literacy, getting the computer to in¬ 
teract with human traits that are the most 
effective for the man-machine interaction. 

“What’s really needed is something in 
the magnitude of a thousand-fold price- 
performance improvement,” Hyatt went 



“I am excited by technology,” Gil Hy¬ 
att told the Compcon audience, “be¬ 
cause we can get these 1,000-fold 
price-performance improvements.” 
Hyatt is currently defending his claim 
to be the first to invent the single-chip 
microprocessor in a US Patent Office 
interference investigation requested by 
Texas Instruments. 


on. “This goal generally is not conceiv¬ 
able by the industry. To tap the visual ca¬ 
pabilities of the mind, you need high-de¬ 
tail images, lots of visual cues, 
three-dimensional cues, full real-time ca¬ 
pability — and this is a wish list that is 
considered to be impossible for a PC- 
type environment. Systems that do small 
portions of this list are in the $100,000 to 
$1 million price range, certainly not suit¬ 
able for a PC.” 

Hyatt did not describe the PC21 in any 
further detail, but declared, “The time 
has never been better for the individual 
inventor. The technology is explosive. 
The markets are enormous. The research 
and development tools are marvelous. It 
is a great environment for the inventor 
and the entrepreneur.” 


Digest of Papers 

The Compcon Spring 91 Digest of 
Papers, Order No. 2134, is available 
from the Computer Society Press, 
Los Alamitos, California, by calling 
(800) CS-BOOKS or (714) 821-8380 
in California. 


Cali for Papers 

Hawaii International Conference on System Sciences - 25 

Koloa, Hawaii, January 7-10,1992 '“J a 

in cooperation with ‘MiSp 

Association for Computing Machinery IEEE Computer Society 


The Software Minitracks of HICSS-25 will address a broad selection of topics in the areas of Rapid 
Prototyping with Reusable Software Components and Prototyping Languages. Please submit 6 copies 
of papers, limited to 22-26 double-spaced, typewritten pages including diagrams, to Prof. Luqi, 
Computer Science Department, Naval Postgraduate School, Monterey, CA 93943. Paper Due: June 
5,1991, Acceptance Notice: August 30,1991, Questions: call (408) 646-2468. 


Rapid Software Prototyping, Luqi, Naval Postgraduate School 

Executable prototypes are developed as an aid for analysis and design of proposed systems. Reuse of 
software components prototyping languages are promising approaches to improving the prototyping 
process. Papers for the rapid prototyping track are solicited on prototyping of hard real-time, parallel, 
distributed, and knowledge-based systems, with emphasis on: 

• Specification for reuse & experiences in using formal methods. 

• Reusable software component retrieval for rapid prototyping 

• Reusable software component integration 

• Fundamental computational models and prototyping languages 

• Transfonnation of prototyping languages into implementation code 

• Prototyping languages which facilitate reuse of software 

• Prototyping languages which bridge the gaps between requirements, specification, design, & 

implementation 












CALL FOR PAPERS 


® IEEE Micro invites authors to submit 
general-interest and theme issue papers 
for publication in 1992 issues. Themes include 
European industry, DSPs, associate memories 
and processors, and ICs for HDTV. Submit six 
copies of each paper to Editor-in-Chief Dante 
Del Corso, Dipartimento di Elettronica, Poli- 
tecnico di Torino, C.so Duca degli Abruzzi, 

24, 10129 Torino, Italy, phone 39 (11) 556- 
7244, Compmail delcorso.d, Internet 
delcorso@pol88B.to.cnr.it, Bitnet delcorso® 
itopoli. For author guidelines, contact Ava 
Marie Fulton at (714) 821-8380. 

UIST 91, Fourth Symp. on User Interface 
Software and Tech.: Nov. 11-13, 1991, Hilton 
Head, S.C. Cosponsors: ACM SIGGraph and 


SIGCHI. Submit paper and panel proposal by 
May 21,1991, to Jock Mackinlay, Xerox PARC, 
3333 Coyote Hill Rd„ Palo Alto, CA 94304, 
phone (415) 494-4335, fax (415) 494-4777, 
e-mail macklinlay.parc@xerox.com. 


1991 Workshop on the High-Order 
V57 Language Theorem-Proving System 
and Its Applications: Aug. 27-30, 1991, 
Davis, Calif. Sponsors: IEEE Computer Soc. 
Technical Committee on Design Automation 
et al. Submit seven copies of 1,000-word ab¬ 
stract by May 29, 1991, to Phil Windley, 
Computer Science Dept., Univ. of Idaho, Mos¬ 
cow, ID 83843, phone (208) 885-6501, fax 
(208) 885-6645, e-mail windley@cs.uidaho. 
edu. 


Mhi 11th IEEE Symp. on Mass Storage 
v87 Systems: Oct. 7-10, 1991, Monterey, 
Calif. Sponsor: IEEE Computer Soc. Techni¬ 
cal Committee on Mass Storage Systems and 
Tech. Submit final papers by May 30, 1991, 
to Bernard T. O’Lear, NCAR, PO Box 3000, 
Boulder, CO 80307, phone (303) 497-1268, 
fax (303) 497-1137. 

Third Int’I Symp. on Parallel and 

Distributed Processing: Dec. 1-5, 
1991, Dallas. Submit paper by May 31, 1991, 
to Behrooz Shirazi, Univ. of Texas at Arling¬ 
ton, Computer Science Eng. Dept., Box 
19015, Arlington, TX 76019-0015, phone 
(817) 273-3605, fax (817) 273-2548, e-mail 
shirazi@evax.utarl.edu. 


Call for articles and referees for Computer 


Computer seeks articles for inclusion in upcoming 
special issues. 

Document Image Analysis Systems is the theme 
planned for the June 1992 issue. Manuscripts reporting sur¬ 
vey, original research, design and development, and applica¬ 
tions of document image analysis are sought immediately. 
See p. 109 of the March 1991 issue for complete information. 

Fourteen copies of the complete manuscript are due by 
July 1, 1991; notification of decisions is set December 1, 
1991; and the deadline for submittal of the final version of 
each manuscript is February 1, 1992. 

Submissions and questions should be directed to Ranga- 
char Kasturi, Electrical and Computer Engineering Depart¬ 
ment, Pennsylvania State University, University Park, PA 
16802, phone (814) 863-4254, e-mail kasturi@cmpe.psu. 
edu; or Lawrence O’Gorman, Room 3D-455, AT&T Bell Labs, 
Murray Hill, NJ 07974, phone (201) 582-7262, e-mail log® 
research.att.com. 

Wafer Scale Integration: Architectures and Algorithms 

will be the theme of the April 1992 issue. See p. 109 of the 
February 1991 issue for complete details. 

Twelve copies of each complete manuscript are due by 
June 15,1991. Notification of decisions is set October 1, 


1991, and the deadline for submitting the final version of the 
manuscript is December 1, 1991. 

Submissions and questions should be directed to W. Kent 
Fuchs, Center for Reliable and High-Performance Comput¬ 
ing, Coordinated Science Laboratory, University of Illinois at 
Urbana-Champaign, 1101 W. Springfield Ave., Urbana, IL 
61801, phone (217) 333-9731, fax (217) 244-1764, e-mail 
fuchs@crhc.uiuc.edu. Questions can also be directed to Earl 
Swartzlander, Department of Electrical and Computer Engi¬ 
neering, ENS Building, Room 517, University of Texas at 
Austin, Austin, TX 78712, phone (512) 471-5923. 

Computer Architectures for Intelligent Systems has 

been selected as the theme for the special May 1992 issue. 
Manuscripts are sought reporting survey, original research, 
design and development, and applications of multimedia 
technology. See p. 102 of the April 1991 issue for complete 
information. 

Submit 12 copies of the full manuscript by June 1, 1991, 
to Jayantha Herath, Dept, of Electrical and Computer 
Engineering, Drexel Univ., Philadelphia, PA 19104, phone 
(215) 895-6758, fax (215) 895-1695, e-mail jheraz@ocs. 
drexel.edu. Notification of decisions is set for November 
1, 1991, and the final version of the manuscript is due 
January 1, 1992. 


For submittal to Computer, manuscripts must not have been previously published or currently submitted for publica¬ 
tion elsewhere. Each manuscript should be no more than 32 typewritten, double-spaced pages long, including all text, 
figures, and references. Each of the 12 copies submitted should include a cover page that contains the title of the arti¬ 
cle, the full name(s) and affiliation(s) of the author(s), complete postal and electronic address(es) of all the authors as 
well as their telephone and fax number(s), a 300-word abstract, and a list of keywords identifying the central issues of 
the manuscript’s contents. The final manuscript should be approximately 8,000 words in length and contain no more 
than 12 references. 

If you are willing to review articles for any of these special issues, please send a note listing your research interests 
to one of the guest editors listed for the particular issue or to Jon T. Butler, editor-in-chief of Computer, at the Depart¬ 
ment of Electrical and Computer Engineering, Naval Postgraduate School, Code EC/Bu, Monterey, CA 92943-5004, 
phone (408) 646-3299 or (408) 646-3041, fax (408) 646-2760, Internet butler@ece.nps.navy.mil. 
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(cjpfe IEEE/ACM Int’I Conf. on Developing 
and Managing Expert System Pro¬ 
grams: Sept. 30-Oct. 2, 1991, Washington, 
DC. Submit five copies of complete paper by 
May 31,1991, to Larry Medsker, Computer 
Science and Information Systems Dept., 
American Univ., Washington, DC 20016. 


IJCNN 91 Singapore, Int’I Conf. on Neural 
Networks: Nov. 18-21, 1991, Singapore. Co¬ 
sponsors: IEEE Neural Networks Council, 

Int’I Neural Networks Soc. Submit one origi¬ 
nal and seven copies of full paper by May 31, 
1991. to Nomi Feldman, Meeting Manage¬ 
ment, 5565 Oberlin Dr., Suite 110, San Diego, 
CA 92121, fax (619) 535-3880 (for US sub¬ 
mittals); Toshio Fukuda, IJCNN 91 Singapore, 
Mechanical Eng. Dept., Nagoya Univ., Furo- 
cho, Chikusa-ku, Nagoya 464-01, Japan, fax 
81 (52) 3781-9243 (submittals in Japan); or 
Teck-Seng Low, IJCNN 91 Singapore, Comm. 
Int’I Associates Pte. Ltd., 44/46 Tanjong Pa- 
gar Rd., Singapore 0208, phone (65) 226- 
2838, fax (65) 226-2877 (all other regions). 


Int’I J. of Computer-Aided VLSI Design 
plans a special issue on high-speed circuits 
and interconnects. Publisher: Ablex. Submit 
five copies of full paper by May 31,1991, to 
S. Chowdhury, Electrical and Computer Eng. 
Dept., Univ. of Iowa, Iowa City, IA 52242, 
phone (319) 335-6052, fax (319) 335-6028, 
e-mail salim@hitchcock.eng.uiowa.edu. 

1991 Lasers in Graphics/Electronic Design 
in Print Conf.: Oct. 26-31, 1991, Ft. Lauder¬ 
dale, Fla. Submit proposed presentation by 
May 31, 1991, to Patrice M. Dunn, c/o Dunn 
Technology Inc., 1855 E. Vista Way, Vista, 
CA 92084, fax (619) 758-5401. 

® 25th Asilomar Conf. on Signals, Sys¬ 
tems, and Computers: Nov. 4-6, 1991, 
Pacific Grove, Calif. Sponsors: Naval Post¬ 
graduate School, San Jose State Univ. Submit 
three copies of 100-word abstract and exten¬ 
sive summary by June 1,1991, to Neil K. 
Jablon, AT&T Bell Labs, 200 Laurel Ave., 
Rm. 1G-540, Middletown, NJ 07748-4801 
phone (201)957-2011. 


( frjj ) Fifth lnt’1 Conf. on VLSI Design: Jan. 

4-7, 1992, Bangalore, India. Sponsor: 
VLSI Soc. of India et al. Submit six copies of 
paper by June 1, 1991, to Yashwant K. 
Malaiya, Computer Science Dept., Colorado 
State Univ., Fort Collins, CO 80523, phone 
(303) 491-7031; or K.S. Raghunathan, Micro¬ 
electronic and Computer Division, Indian 
Telephone Industries, Bangalore, 560016, In¬ 
dia, phone 91 (812) 563-211. 


ISMM, Int’l Symp. on Microcomputer Ap¬ 
plications: Dec. 11-13,1991, Long Beach, 
Calif. Submit three copies of paper by June 1, 
1991, to Donna Hudson, Univ. of California at 
San Francisco, 2615 E. Clinton Ave., Fresno, 
CA 93703, phone (209) 225-6100, ext. 5776, 
fax (209) 228-6929, e-mail hudson@mis. 
ucsf.edu (for papers on microcomputers in 
medicine); or Les Miller, Computer Science 
Dept, 226 Atanasoff Hall, Iowa State Univ., 
Ames, IA 50011, phone (515) 294-4377, fax 


(515) 294-2574, e-mail lmiller@atanasoff. 
cs.iastate.edu (for papers on engineering and 
industrial applications). 


Symp. on Formal Techniques in Real-Time 
and Fault-Tolerant Systems: Jan. 6-10, 

1992, Nijmegen, the Netherlands. Submit four 
copies of paper by June 1,1991, to Jan Vyto- 
pil, Real-Time Systems Group, Informatics 
Dept., Univ. of Nijmegen, Toemooiveld, 6525 
ED Nijmegen, the Netherlands, phone 31 (80) 
652-075, fax 31 (80) 553-450, e-mail 
vytopil@cs.kun.nl. 


Hawaii Int’l Conf. on Systems Sci- 
ences: Jan. 7-10, 1992, Koloa, Hawaii. 
Cosponsors: IEEE, ACM. Submit six copies 
of paper by June 5, 1991, to Luqi, Computer 
Science Dept, Naval Postgraduate School, 
Monterey, CA 93940, phone (408) 646-2468. 

Eighth Int’l Conf. on Data Eng.: Feb. 
3-7, 1992, Phoenix, Ariz. Submit five 
copies of complete paper by June 7,1991, 
and camera-ready version by Oct. 31,1991, to 
Forouzan Golshani, Computer Science and 
Eng. Dept., Arizona State Univ., Tempe, AZ 
85287-5406, phone (602) 965-2855, e-mail 
golshani@asuvax.eas.asu.edu. 


1992 Conf. of the Assoc, for Information 
and Image Management: June 22-25, 1991, 
Anaheim, Calif. Submit completed abstract 
submission kit by June 7,1991. To obtain a 
kit, contact AIIM, Education Dept., 1100 
Wayne Ave., Suite 1100, Silver Spring, MD 
20910, phone (301) 587-8202, fax (301) 587- 
2711. 


Electrosoft plans a special issue on software 
for system transient modeling. Submit three 
copies of paper by June 8, 1991, to H.W. 
Dommel, Electrical Eng. Dept., Univ. of Brit¬ 
ish Columbia, 2356 Main Mall, Vancouver, 
B.C., Canada V6T 1W5, phone (604) 228- 
2793. 


Fourth Int’l Conf. on Image Processing and 
Its Applications: Apr. 7-9, 1992, Maastricht, 
the Netherlands. Sponsor: Institution of Elec¬ 
trical Engineers. Submit synopsis by June 12, 
1991, and full text by Nov. 29,1991, to IEE 
Conf. Services, Savoy Place, London WC2R 
0BL, UK, phone (071) 240-1871, fax (071) 
240-7735. 


IEEE Software plans a special issue on 
N5Z integrated computer-aided software en¬ 
gineering in March 1992. Papers are invited 
that may be theoretical, conceptual, or empiri¬ 
cal in nature, with special interest given to 
those detailing solutions to practical integrat¬ 
ed CASE problems. Late submissions will be 
accepted until June 15, 1991. Submit seven 
copies of manuscript to Ronald J. Norman, 
IDS Dept., San Diego State Univ., San Diego, 
CA 92182-0127, phone (619) 594-3734, fax 
(619) 594-1573, Internet rnorman@sciences. 
sdsu.edu. 


jjrf hjj} Micro 24, 24th ACM/IEEE Int’I 
V&Z Symp. and Workshop on Microarchi¬ 
tecture: Nov. 18-20, 1991, Albuquerque, 
N.M. Submit four copies of manuscript by 
June 15, 1991, and final version by Sept. 17, 


1991, to (by geographical region) Andrew 
Wolfe, Electrical and Computer Science 
Dept., Carnegie Mellon Univ., Pittsburgh, PA 
15213-3890, phone (412) 268-7102, fax (412) 
268-2860, e-mail wolfe@ece.cmu.edu; Toshio 
Nakatani, IBM Japan, 5-19, Sanbancho, 
Chiyoda-ku, Tokyo 102, Japan, phone 81 (03) 
288-8409, fax 81 (03) 265-4251, e-mail 
nakatani @trlvm3.iinus 1 .ibm.com or 
nakatani@jpntscvm.bitnet; or Hans Mulder, 
Electrical Eng. Dept., Delft Univ. of Tech. PO 
Box 5031, 2600 GA Delft, the Netherlands, 
phone 31 (0) 1578-5021, fax 31 (0) 1578- 
4898, e-mail hansm@duteca.et.tudelft.nl. 

Int’l J. on Eng. Applications of Artificial In¬ 
telligence plans a special issue on neural net¬ 
works and parallel processing. Publisher: Per- 
gamon Press. Submit four copies of full paper 
by June 15,1991, to Nikolaus G. Bourbakis, 
4138 Moonflower Ct„ San Jose, CA 95135, 
phone (408) 270-3455, fax (408) 256-6760. 

EDBT 92, Int’l Conf. on Extending Data¬ 
base Tech.: Mar. 23-27, 1992, Vienna. Spon¬ 
sor: IEEE. Submit five copies of complete pa¬ 
per by June 20,1991, to Alain Pirotte, Philips 
Research Lab Belgium, Avenue Albert Ein¬ 
stein 4, B-1348 Louvain-la-Neuve, Belgium, 
e-mail pirotte@prlb.philips.be. 

/gi) IEEE Infocom 92, 11th Conf. on 
Computer Comm.: May 4-8, 1992, 
Florence, Italy. Cosponsor: IEEE Comm. Soc. 
Submit six copies of paper by June 30, 1991, 
to L. Fratta, Politecnico di Milano, c/o Cefriel, 
Via Emanueli, 15, 20126 Milano, Italy, phone 
39 (2) 2399-3578, fax 39 (2) 2399-3587, 
e-mail fratta@imicefr.bitnet; or J. Kurose, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-1585, e-mail kurose@ 
cs.umass.edu. 


IEEE Trans, on Computers plans a 
N&Z special issue on fault-tolerant comput¬ 
ing in May 1992. Submit seven copies of 
manuscript by July 1, 1991, to W. Kent 
Fuchs, 1101 W. Springfield Ave., Coordinated 
Science Lab, Univ. of Illinois, Urbana, IL 
61801, phone (217) 333-9731, e-mail fuchs@ 
crhc.uiuc.edu. 


Int’l J. of Microcomputer Applications seeks 
original research papers on microcomputer ap¬ 
plications for a special issue on control. Sub¬ 
mit three copies of paper by July 1,1991, to 
Les Miller, Computer Science Dept, 226 Ata¬ 
nasoff Hall, Iowa State Univ., Ames, IA 
50011, phone (515) 294-4377, fax (515) 294- 
2574, e-mail lmiller@atanasoff.cs.iastate.edu. 

Int’l J. of Applied Intelligence plans a special 
issue in March 1992 on distributed artificial 
intelligence in manufacturing. Publisher: Klu- 
wer. Submit paper by July 1, 1991. to Mark S. 
Fox, Guest Editor, c/o Karen S. Cullen, Klu- 
wer Academic Publishers, 101 Philip Dr., 
Norwell, MA 02061. 

SETSS 92, Eighth Int’l Conf. on Software 
Eng. for Telecommunication Systems and 
Services: Mar. 30-Apr. 1, 1992, Florence, 
Italy. Sponsor: Institution of Electrical Engi¬ 
neers. Submit synopsis by July 1,1991, to 
IEE Conf. Services, Savoy Place, London 


COMPUTER 






Int’l J. of Expert Systems: Research and Ap¬ 
plications plans a special issue in March 1992 
on research in case-based expert systems. 
Submit manuscript by July 1,1991, to Evan- 
gelos Simoudis, AI Applications Group, DEC, 
290 Donald Lynch Blvd., MS DLB5-2/B4, 
Marlboro, MA 01752, phone (508) 490-8141, 
e-mail simoudis@aiag.enet.dec.com. 

Third NASA Symp. on VLSI Design: Oct. 
30-31, 1991, Moscow, Idaho. Cosponsors: 
IEEE Section of Spokane, Wash., Univ. of 
Idaho NASA Space Eng. Research Center. 
Submit four copies of 500-word summary and 
50-word abstract by July 1,1991, and final 
paper by Sept. 1, 1991, to Judy Wood, NASA 
SERC, Univ. of Idaho, Moscow, ID 83843, 
phone (208) 885-6500, fax (208) 885-7579, 
e-mailjwood@groucho.mrc.uidaho.edu. 

© Fourth Int’l Conf. on Strategic Soft¬ 
ware Systems: Mar. 10-11, 1992, 
Huntsville, Ala. Cosponsors: IEEE Computer 
Soc. Huntsville Chapter, Univ. of Alabama in 
Huntsville. Submit abstract by July 15,1991, 
to Ann H. Yelle, Univ. of Alabama in Hunts¬ 
ville, Continuing Education Division, Confer¬ 
ences (SSS-92), Bevill Center 289-A, Hunts¬ 
ville, AL 35899, phone (800) 448-4035 or 
(205) 895-6372, fax (205) 895-6760. 

16th Conf. on Local Computer Net- 
n 57 works: Oct. 14-17, 1991, Minneapolis, 
Minn. Cosponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Comm. Submit 
five copies of camera-ready version by Aug. 

2,1991, to James F. Mollenauer, Technical 
Strategy Associates, 37 Silver Birch Rd., 
Newton, MA 02168, phone and fax (617) 244- 
0077. 

12th IEEE Symp. on Real-Time Sys- 
terns: Dec. 3-6, 1991, San Antonio, 
Texas. Sponsor: IEEE Computer Soc. Techni¬ 
cal Committee on Real-Time Computing. Sub¬ 
mit five copies of extended abstract by Sept. 

2,1991, Lui Sha, Software Eng. Inst., Carne¬ 
gie Mellon Univ., 4500 Fifth Ave., Pittsburgh, 
PA 15213, phone (412) 268-5875, e-mail 
sha@sei.cmu.edu. 

® ICSE 92,14th Int’l Conf. on Software 
Eng.: May 11-15, 1992, Melbourne, 
Australia. Cosponsors: IEEE Computer Soc. et 
al. Submit six copies of full paper or experi¬ 
ence report by Sept. 6,1991, to A.Y. Mont¬ 
gomery, Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 (3) 
660-2943, fax 61 (3) 662-1617, e-mail 
aym@goanna.cs.rmit.oz.au. 

IEA/AIE 92, Fifth Int’l Conf. on In- 
vS?' dustrial and Eng. Applications of Ar¬ 
tificial Intelligence and Expert Systems: 

June 9-12,1992, Paderborn, Germany. Co¬ 
sponsors: Univ. of Paderborn et al. Submit six 
copies of paper by Nov. 1,1991, to Fevri Bel¬ 
li, Univ. of Paderborn, Postfash 1621, 4790 
Paderborn, Germany, phone 49 (5251) 60- 
3282, e-mail belli@adt.uni-paderbom.de. 


CALL FOR PARTICIPATION 

^ The 1991 International Tutorial and Workshop on t he 
* HOL Theorem Proving System and Its Applications /f~\ 
Davis, California, USA August 27 and August 28—30,1991 

The HOL system is a higher-order-logic theorem proving system implemented at Cam¬ 
bridge University using methods developed at Edinburgh University. It has found many 
applications, from the verification of hardware designs at all levels to the verification of 
programs and communication protocols. 

This workshop is intended to bring together developers, users, potential users, and others 
interested in the HOL theorem proving system to share information on new development, 
extensions, and applications of HOL, and to discuss future directions for improvements to 
HOL and its interfaces. 

The 3-day workshop will be preceded by a full-day tutorial on August 21th, with presenta¬ 
tions by a panel of invited HOL experts on a range of topics, including: an overview of the 
system; a survey of applications; comparison of HOL with other interactive verification 
systems; what helps and what hinders new users; the integration of HOL with existing 
methodologies, tools and environments. This tutorial is designed for an audience not 
necessarily familiar with the HOL system or its applications. It is intended primarily to 
give prospective users an informed basis for evaluating the HOL system and its potential. 
Papers are invited on new developments and extensions to HOL, applications of HOL, 
HOL proof techniques, user interfaces for HOL and interfaces between HOL and other 
systems, comparison of HOL with other verification systems, and progress in other 
higher-order-logic proving systems. Panel proposals also will be entertained. 

Authors should send seven copies of a 1000 word abstract or panel proposal to Phil Wind- 
ley. Electronic mail submissions in PostScript format will also be accepted, for the con¬ 
venience of European participants. Abstracts or proposals must be received by May 29, 
1991. Notification of acceptance will be made by July 1, 1991. Papers accepted for the 
workshop will be published in a Proceedings. 

Non-authors are also encouraged to participate in the tutorial and/or workshop; contact 
Myla Archer. Travel scholarships for amounts up to $1,000 may be available for full-time 
students, on a competitive basis. For details, write to Jeff Joyce. 

Co-sponsors: IEEE Computer Society, ACM SIGDA, UC Davis, UBC, U Idaho 
Program Committee: 

Myla Archer Luc Claesen Elsa Gunter Jeff Joyce TomMelham 

Graham Birtwistle Avra Cohn John Herbert Karl Levitt Phil Windley 

Shui-Kai Chin Michael Gordon Roger Jones Paul Loewenstein Glynn Winskel 
Organizing Committee: 

Myla Archer (General Chair), archer@cs.ucdavis.edu, (916)752-7583, -4767 (fax) 

Karl Levitt (Financial Chair), levitt@cs.ucdavis.edu, (916)752-0832, -4767 (fax) 

Division of Computer Science, University of California, Davis, Davis, CA 95616, USA 
Jeff Joyce (Tutorials Chair), joyce@cs.ubc.ca, (604)228-4327, -5485 (fax) 

Dept, of Comp. Sci., Univ. of British Columbia, Vancouver, BC V6T 1W5, CANADA 
Phil Windley (Program Chair), windley@cs.uidaho.edu, (208)885-6501, -6645 (fax) 
Department of Computer Science, University of Idaho, Moscow, ID 83843, USA 
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CALENDAR 


May 1991 


® 1991 Tahoe Computer Packaging 
Workshop, May 19-20, Tahoe City, 
Calif. Sponsor; IEEE Computer Soc. Techni¬ 
cal Committee on Computer Packaging. Con¬ 
tact Bhadrik S. Dalai, Amdahl, MS 324, 1250 
E. Arques Ave., Sunnyvale, CA 94088-3470, 
phone (408) 746-8203, fax (408) 746-7717. 

Workshop on Parallel and Distributed De¬ 
bugging, May 20-21, Santa Cruz, Calif. Co¬ 
sponsors: ACM, US Navy Office of Naval Re¬ 
search. Contact Bart Miller, Computer 
Science Dept., Univ. of Wisconsin, 1210 W. 
Dayton St., Madison, WI 53706, phone (608) 
263-3378, Internet bart@cs.wisc.edu. 


/ijhJj 1991 IEEE Symp. on Research in 
Security and Privacy, May 20-22, 

Oakland, Calif. Sponsor: IEEE Computer Soc. 
Technical Committee on Security and Privacy. 
Contact Daniel Schnackenberg, Boeing, MS 
9P-64, PO Box 3999, Seattle, WA 98124, 
phone (206) 657-5595, e-mail 
schnackenberg@dockmaster.ncsc.mil. 


Second Physical Design Workshop, May 20- 

22, Laurel Highlands, Pa. Sponsor: ACM 
SIGDA. Contact Mary Jane Irwin, Pennsylva¬ 
nia State Univ., Computer Science Dept., Uni¬ 
versity Park, PA 16802, phone (814) 865- 
1802, e-mail mji@guardian.cs.psu.edu; or 
Antun Domic, HL02-3J3, DEC, 77 Reed Rd„ 
Hudson, MA 01749, e-mail domic @cadsys. 


ICDCS 91, 11th Int’l Conf. on Dis- 
tributed Computing Systems, May 
20-24, Arlington, Texas. Contact Bill D. Car- 
roll, Computer Science Eng. Dept., Univ. of 
Texas at Arlington, Box 19015, Arlington, TX 
76019-0015, phone (817) 273-3787, fax (817) 
273-2548, e-mail carroll@evax.utarl.edu. 

SESAW, Fourth Software Eng. Stan- 
v57 dards Application Workshop, May 
20-24, San Diego, Calif. Contact Vera V. 
Edelstein, Nynex, 500 Westchester Ave., 
White Plains, NY 10604, phone (914) 683- 


EKAW 91, Fifth European Knowledge Ac¬ 
quisition for Knowledge-Based Systems 
Workshop, May 20-24, Crieff, Scotland. 
Contact Duncan Smeed, Computer Science 
Dept., Univ. of Strathclyde, Livingstone Tow¬ 
er, 26 Richmond St., Glasgow G1 1XH, Scot¬ 
land, phone (041-552) 4400. 

Eur-Open, Spring 1991 European Forum 
for Open Systems, May 20-24, Tromso, Nor¬ 
way. Contact Eur-Open Secretariat, Owles 
Hall, Buntingford, Herts. SG9 9PL, UK, 
phone 44 (763) 73039, fax 44 (763) 73255, 
e-mail europen@eu.net. 


In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is participating 
in or sponsoring. Other conferences of interest to our readers — as well as their 
sponsors — are also listed. 

Calendar and Call for Papers notices are published free of charge, in chrono¬ 
logical order, and as space permits. 

When submitting information for inclusion in the Call for Papers section, please 
provide the following: the name of the event, the date(s), the location, the 
sponsor(s), the deadline for submittals, and the phone and fax numbers and — if 
applicable — the electronic address of the person to whom papers should be 
sent. 

For listings in the Calendar section, please provide the following: the event 
name, the date(s), the location, the sponsor(s), and the phone and fax numbers 
and — if applicable — and electronic address of the person to contact for com¬ 
plete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the July 1991 issue, send information for re¬ 
ceipt by May 20,1991) to Chuck Governale, Calendar Dept., Computer, PO Box 
3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail c.governale® 
compmail.com. 


SCAI 91, Third Scandinavian Conf. on Ar¬ 
tificial Intelligence, May 21-24, Roskilde, 
Denmark. Contact Brian Mayoh, Computer 
Science Dept., Aarhus Univ., Ny Munkegade, 
Bldg. 540, DK-8000 Aarhus C, Denmark, 
phone 45 (86) 127188, fax 45 (86) 135725 
e-mail brian@daxmi.aau.dk. 


1991 ACM SIGMetrics Conf. on Measure¬ 
ment and Modeling of Computer Systems, 
May 21-24, San Diego, Calif. Contact Mi¬ 
chael Molloy, Hewlett-Packard, 3404 E. Har¬ 
mony Rd., Fort Collins, CO 80525, phone 
(303) 229-6367, e-mail molloy%hpfcda@ 
hp.com. 

Second Int’l Conf. on Algebraic Methodolo¬ 
gy and Software Tech., May 22-24, Iowa 
City, Iowa. Contact Teodor Rus, Computer 
Science Dept., Univ. of Iowa, Iowa City, IA 
52242, phone (319) 335-0694, e-mail rus@ 
herky.cs.uiowa.edu. 

Melecon 91, Fifth Mediterranean Electro¬ 
technical Conf., May 22-24, Ljubljana, Yu¬ 
goslavia. Cosponsors: IEEE Region 8 Yugo¬ 
slavia Section et al. Contact Melecon 91 
Secretariat, Fakulteta za elektrotehniko, Trza- 
ska 25, 61001 Ljubljana, Yugoslavia, phone 
38 (61) 265-161, fax 38 (61) 264-990. 


Workshop on Interconnections With- 
in High-Speed Digital Systems, May 
22-24, Santa Fe, N.M. Cosponsors: IEEE 
Comm. Soc. et al. Contact IEEE Lasers and 
Electro-Optics Soc., 445 Hoes Lane, PO Box 
1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3896, fax (908) 562-1571. 


Workshop on Parallel Computing of Dis¬ 
crete Optimization Problems, May 22-24, 

Minneapolis, Minn. Cosponsors: Univ. of 


Minnesota et al. Contact Vipin Kumar, Univ. 
of Minnesota, Computer Science Dept., Min¬ 
neapolis, MN 55455, phone (612) 624-8023, 
e-mail kumar@umn.ai. 

Instrument Soc. of Am. Conf., May 22-24, 

Birmingham, UK. Sponsor: ISA Int’l Euro¬ 
pean Region. Contact ISA, 67 Alexander Dr., 
PO Box 12277, Research Triangle Park, NC 
22709, phone (919) 549-8411, fax (919) 549- 
8288. 


Computer Animation 91, May 22-25, Gene¬ 
va. Cosponsors: Computer Graphics Soc. Con¬ 
tact Nadia M. Thalmann, Mira Lab CUI, Univ. 
of Geneva, 12 rue du Lac, CH 1207, Geneva, 
Switzerland, phone 41 (22) 787-6581, fax 41 
(22) 735-3905, e-mail thalmann@uni2a. 
unige.ch. 

Third Int’l Conf. on Artificial Intelligence 

and Law, May 25-28, Oxford, England. Co¬ 
sponsors: ACM SIGART, Soc. for Computer 
Law. Contact Carole Hafner, Northeastern 
Univ., College of Computer Science, Boston, 
MA 02115, phone (617) 437-5116, e-mail 
hafner@corwin.ccs.northeastern.edu. 


® 21st Int’l Symp. on Multiple-Valued 
Logic, May 26-29, Victoria, B.C., Can¬ 
ada. Contact D.M. Miller, Computer Science 
Dept., Univ. of Victoria, PO Box 1700, Victo¬ 
ria, B.C., Canada, V8W 2Y2, phone (604) 
721-7220, fax (604) 721-7292, e-mail 
dmill@csr.uvic.cdn. 


® ISCA 18,18th Int’l Symp. on Com¬ 
puter Architecture, May 26-30, 

Toronto. Cosponsor: ACM. Contact K.C. 
Smith, Univ. of Toronto, Electrical Eng. 
Dept., Toronto, Ont. M5S 1A4, Canada, 
phone (416) 978-5033. 
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® Euro AISIC 91, May 27-31, Paris. 

Contact Gabriele Saucier, Inst. Nat’l 
Polytechnic de Grenoble/CSI, 46, avenue Fe¬ 
lix Viallet, 38031 Grenoble Cedex, France, 
phone 33 (9) 7657-4687. 

® Fifth Israel Conf. on Computer Sys¬ 
tems and Software Eng., May 28-29, 

Herzlia, Israel. Sponsors: IEEE Computer 
Soc. Israeli Chapter et al. Contact M. Wino- 
kur, c/o ORTRA, PO Box 50432, Tel Aviv 
61500, Israel, phone 972 (3) 664-825, fax 972 
(3) 660-952. 

|£ji) 1991 IEEE Pacific Northwest Test 
Workshop, May 29-31, Eastsound, 
Wash. Contact Mani Soma, Univ. of Washing¬ 
ton, Electrical Eng. Dept., FT-10, Seattle, WA 
98195, phone (206) 685-3810, fax (206) 543- 
3842. 

ACM 1991 Int’l Conf. on Management of 
Data and 10th ACM Symp. on Principles of 
Database Systems, May 29-31, Denver. 
Sponsors: ACM SIGMOD, SIGACT, 

SIGART. Contact Dan Moore, US West 
Advanced Technology, 6200 S. Quebec St., 
Englewood, CO 80111, phone (303) 930- 
5313, e-mail dan@uswat.uswest.com. 


IEEE Standards Seminars, 445 Hoes Lane, PO 
Box 1331, Piscataway, NJ 08855-1331, phone 
(908) 562-3805. 


June 1991 


SCM 3, Third Int’l Software Configu- 
ration Management Workshop, June 
12-14, Trondheim, Norway. Cosponsors:ACM 
et al. Contact Reidar Conradi, Computer Sys¬ 
tems and Telematics Div., Norwegian Inst, of 
Tech., N-7034 Trondheim, Norway, phone 47 
(7) 593-444; or Peter Feiler, Software Eng. AuCUSt 1991 
Inst., Carnegie Mellon Univ., Pittsburgh, PA & 

15213-3890, phone (412) 268-7790, e-mail 
phf@sei.cmu.edu. 


SIGGraph 91, July 28-Aug. 2, Las 

Vegas. Sponsor: ACM. Contact Assoc, 
for Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869-7440. 


Workshop on Directions in Auto- 
mated CAD-Based Vision, June 2-3, 

Maui, Hawaii. Contact Linda G. Shapiro, 
Computer Science and Eng. Dept., FR-35, 
Univ. of Washington, Seattle, WA 98195, 
phone (206) 543-2196, fax (206) 543-3842. 

/£jfe IEA/AIE 91, Fourth Int’l Conf. on In- 
dustrial and Eng. Applications of Ar¬ 
tificial Intelligence and Expert Systems, 
June 2-5, Kauai, Hawaii. Sponsors: ACM et 
al. Contact Moonis Ali, Univ. of Tennessee 
Space Inst., MS15, B.H. Goethert Pkwy., Tul- 
lahoma, TN 37388-8897, phone (615) 455- 
0631, ext. 236, fax (615) 454-2354, e-mail 
alif@utsivl.bitnet. 

Southwest Test Workshop, June 3-5, 

San Diego, Calif. Sponsor: IEEE Comput¬ 
er Soc. Technical Committee on Test Tech. Con¬ 
tact William R. Mann, Rockwell Int’l, MS 503- 
200,4311 Jamboree, Newport Beach, CA 92660, 
phone (714) 833-4013, fax (714) 833-6680. 

CVPR 91, IEEE Computer Soc. Conf. 
VEY on Computer Vision and Pattern Rec¬ 
ognition, June 3-7, Lahaina, Maui, Hawaii. 
Contact Shahriar Negahdaripour, Electrical 
Eng. Dept., Univ. of Hawaii at Manoa, 2540 
Dole St., Honolulu, HI 96822, e-mail 
shahriar@wiliki.eng.hawaii.edu. 

Graphics/Vision Interface Conf., June 3-7, 

Calgary, Alta., Canada. Contact Billie Sum¬ 
mers, Conf. Office, Univ. of Calgary, 2500 
University Dr. NW, Calgary, Alta., Canada 
T2N 1N4, phone (403) 220-4987, fax (403) 
289-7287. 


DAC 91,28th ACM/IEEE Design 
Automation Conf., June 17-21, San 

Francisco. Contact MP Associates, 7490 Club¬ 
house Rd., Suite 102, Boulder, CO 80301, 
phone (303) 530-4333. 

Computer Security Foundations IV, 
June 18-20, Franconia, N.H. Sponsor: 
IEEE Computer Soc. Technical Committee on 
Security and Privacy. Contact J. Thomas 
Hargh, Secure Computing Tech., 1210 W. 
County Rd. E, Arden Hills, MN 55112, phone 
(612) 482-7428, fax (612) 482-7401. 

/£3ij CGI 91, Int’l Conf. on Computer 
Graphics, June 22-28, Cambridge, 
Mass. Cosponsors: Computer Graphics Soc., 
MIT. Contact Barbara Dullea, Ocean Eng. 
Dept., MIT Rm. 5-435, 77 Massachusetts 
Ave., Cambridge, MA 02139, fax (617) 253- 
8125, e-mail barbara@deslab.mit.edu. 

|£ji| FTCS 21, 21st Int’l Symp. on Fault- 
Tolerant Computing, June 25-27, 

Montreal. Sponsor: IEEE Computer Soc. 
Technical Committee on Fault-Tolerant Com¬ 
puting. Contact Vinod K. Agarwal, McGill 
Univ., Electrical Eng. Dept., 3480 University 
St., Montreal, Que., Canada H3A 2A7, phone 
(514) 398-7136, fax (514) 398-4470, e-mail 
agarwal @ spock.ee.mcgill.ca. 

Zrj-ij Arith 10, 10th Symp. on Computer 
Arithmetic, June 26-28, Grenoble, 
France. Cosponsors: ACM et al. Contact Jean- 
Michel Muller, Lab. LIP-IMAC, Ens. Lyon, 
69364 Lyon Cedex 07, France, phone 33 (72) 
72-8229. 


July 1991 


® CAR 91, Fifth Int’l Symp. on Com¬ 
puter-Assisted Radiology, July 3-6, 
Berlin. Sponsor: Technical Univ. of Berlin. 
Contact Heinz U. Lemke, Inst, for Technical 
Computer Science, Sekr CG-FR3-3, Franklin- 
strasse 28-29, D-1000, Berlin 10, Germany, 
phone 49 (30) 314-73100; or Michael H. 
Rhodes, Toshiba America MRI, 280 Utah 
Ave., South San Francisco, CA 94080, phone 
(415) 875-2909. 

Operating Systems of the 90s and Be- 
yond, July 8-12, Dagstuhl, Germany. 
Contact Arthur I. Karshmer, New Mexico 
State Univ., Computer Science Dept., PO Box 
30001, Dept. 3CU, Las Cruces, NM 88003- 


® Crypto 91, Aug. 11-15, Santa Barbara, 
Calif. Cosponsors: Int’l Assoc, for 
Cryptologic Research et al. Contact Burt 
Kaliski, Crypto 91, RSA Data Security, 10 
Twin Dolphin Dr., Redwood City, CA 94065, 
phone (415) 595-8782, fax (415) 595-1873, 
Internet: burt@rsa.com. 

j£jit Hot Chips III Symp., Aug. 26-27, 

Stanford, Calif. Sponsor: IEEE Comput¬ 
er Soc. Technical Committee on Microproces¬ 
sors and Microcomputers. Contact Martin 
Freeman, Philips Research Labs, Signetics MS 
02, 811 E. Arques Ave., Sunnyvale, CA 
94086, phone (408) 991-3591, fax (408) 991- 
4077, e-mail mfreeman@sierra.stanford.edu; 
or Melissa Anderson, Silicon Graphics, 2011 
N. Shoreline Blvd., PO Box 7311, Mountain 
View, CA 94039-7311, phone (415) 335-1565, 
fax (415) 965-7651, e-mail mda@sgi. com. 

Tencon 91, 1991 IEEE Region 10 
Conf., Aug. 26-30, New' Delhi, India. 
Contact H.L. Bajaj, B-101 Hillview Apts., Va- 
sant Aihar, New Delhi 110057, India, phone 
91 (11) 36-0412, fax 91 (11) 36-1018; or A.L. 
Lakshminarasimhan, AT&T Bell Labs, 480 
Red Hill Rd., No. HR 2E030, Middletown, NJ 
07748, phone (201) 615-4524. 

1991 Workshop on the High-Order 
Language Theorem-Proving System 
and Its Applications, Aug. 27-30, Davis, 
Calif. Sponsors: IEEE Computer Soc. Techni¬ 
cal Committee on Design Automation et al. 
Contact Myla Archer, Computer Science Divi¬ 
sion, Univ. of California at Davis, Davis, CA 
95616, phone (916) 752-7583, fax (916) 752- 
4767, e-mail archer@eecs.ucdavis.edu. 

f£j^} SSD 91, Second Symp. on Large Spa¬ 
vin tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact Hans-J. Schek, Inst, fur 
Information Systeme, Eth Zentrum, CH-8092 
Zurich, Switzerland, phone 41 (1) 254-7240, 
fax 41 (1)262-3973, e-mail 
schek@inf.ethz.ch. 


September 1991 

jijij Int’l Conf. on Application-Specific 
N57 Array Processors, Sept. 2-4, Barcelo¬ 
na, Spain. Sponsor: Princeton Univ. Contact 
S.Y. Kung, Electrical Eng. Dept., Princeton 
Univ., Princeton, NJ 08554, phone (609) 258- 
3780, fax (609) 258-3745. 

/gjj VLDB 91, 17th Int’l Conf. on Very 
Large Data Bases, Sept. 3-6, Barcelo¬ 
na, Spain. Sponsors: IEEE Computer Soc. 
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Technical Committee on Data Eng. et al. Con¬ 
tact Guy M. Lohman, IBM Almaden Research 
Center, Dept. K55, Bldg. 801, 650 Harry Rd„ 
San Jose, CA 95120-6099, Internet lohman @ 
ibm.com, Bitnet lohman@almaden. 


Compsac 91,15th Int’I Computer October 1991 
vU' Software and Applications Conf., 

Sept. 11-13, Tokyo. Cosponsor: Information 
Processing Soc. of Japan. Contact Stephen S. 

Yau, Univ. of Florida, CIS Dept., Rm. 301, 

Gainesville, FL 32611, phone (904) 335-8006 
or (904) 392-1212, fax (904) 392-1220, e-mail 
yau@cis.ufl.edu. 


Campus Universitaire de Beaulieu, 35042 
Rennes Cedex, France, phone (33) 9936-2000, 
fax (33) 9938-32. 


/Qjj Fourth Artificial Intelligence Symp., 
Sept. 20-21, Fredericton, N.B., Canada. 
Sponsor: Univ. of New Brunswick. Contact 
Brad Nickerson, Computer Science Faculty, 
Univ. of New Brunswick, Fredericton, N.B., 
Canada E3B 5A3, phone (506) 453-4566, fax 
(506) 453-3566, e-mail bgn@unb.ca. 

f£j^v First Int’I Workshop on the Econom- 
sgy ics of Design and Test, Sept. 23-25, 

Austin, Texas. Sponsor: ACM. Contact Mag- 
dy Abadir, MCC CAD Program, 3500 W. Bal- 
cones Center Dr., Austin, TX 78759, phone 
(512) 338-3611, fax (512) 338-3600; or A.P. 
Ambler, Brunei Univ., Dept, of Electrical 
Eng. and Electronics, Uxbridge, Middx, UB8 
3PH, UK, phone (44) 895-74000, fax (44) 
895-58728. 

/gjji ASIC 91, Fourth IEEE Int’I Applica- 
viy tion-Specific Integrated Circuits 
Conf., Sept. 23-27, Rochester, N.Y. Sponsor: 
IEEE Rochester Section. Contact Lynne M. 
Engelbrecht, ASIC 91, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328-2310, 
fax (716) 436-9370. 

(£|^\ Pacific Rim Int’I Symp. on Fault- 
Tolerant Systems, Sept. 26-27, Ka¬ 
wasaki, Japan. Sponsor: Inst, of Electrical, In¬ 
formation, and Comm. Eng. Contact Sachio 
Naito, Electrical Eng. Dept., Nagaoka Univ. 
of Tech., 1603-1 Kamitomioka, Nagaoka, Ni¬ 
igata, 940-21, Japan, phone 81 (258) 46-6000, 
ext. 5110, fax 81 (258) 46-6506. 

j ^f^ j IEEE/ACM Int’I Conf. on Developing 
V57 and Managing Expert System Pro¬ 
grams and Projects, Sept. 30-Oct. 2, Wash¬ 
ington, DC. Contact Jerald Feinstein, Mitre, 
7325 Colshire Dr., McLean, VA 22102, phone 
(703) 883-6236, fax (703) 821-0701; or Larry 
Medsker, Computer Science and Information 
Systems Dept., American Univ., Washington, 
DC 20016. 

® 10th Symp. on Reliable Distributed 
Systems, Sept. 30-Oct. 2, Pisa, Italy. 
Contact Luca Simoncini, IEI-CNR, Via S. 
Maria 46, 56100 Pisa, Italy, phone 39 (50) 
553-159, fax 39 (50) 554-342; or Ozalp 
Babaoglu, Dip. di Matematica, Univ. di Bolo¬ 
gna, Piazza di Porta S. Donato, 5, 40127 Bo¬ 
logna, Italy, phone 39 (51) 354-430, fax 39 
(51) 354-490, e-mail ozalp@dm.unibo.it. 

/£f^j First Int’l Conf. on Document Analy- 
sis and Recognition, Sept. 30-Oct. 2, 

Saint-Malo, France. Cosponsors: Assoc. Fran- 
caise pour la Cybernetique Economique et 
Technique et al. Contact Guy Lorette, IRISA- 


IEEE Workshop on Visual Motion, 
Oct. 6-9. Princeton, N.J. Contact Peter 
Burt, David Samoff Research Center, 201 
Washington Rd., Princeton, NJ 08540, e-mail 
burt@vision.samoff.com. 

CSEE 91, Fifth Conf. on Software 
Eng. Education, Oct. 7-8, Pittsburgh. 
Sponsor: Software Eng. Inst. Contact James E. 
Tomayko, SEI, Carnegie Mellon Univ., 4500 
Fifth Ave., Pittsburgh, PA 15213-3890, phone 
(412) 268-6806, fax (412) 268-5758, e-mail 
jet@sei.cmu.edu. 

llth IEEE Symp. on Mass Storage 
Systems, Oct. 7-10, Monterey, Calif. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Mass Storage Systems and 
Tech. Contact Bernard T. O’Lear, NCAR, PO 
Box 3000, Boulder, CO 80307, phone (303) 
497-1268, fax (303) 497-1137. 

Symp. on Testing, Analysis, and Veri- 
fication, Oct. 8-10, Victoria, B.C., Can¬ 
ada. Sponsors: IEEE Computer Soc., ACM 
SIGSoft. Contact Nancy Leveson, Computer 
Science Dept., Univ. of California, Irvine, CA 
92717, phone (714) 856-5517, e-mail nancy@ 
ics.uci.edu. 

First Int’I Conf. on Artificial Intelli- 
V57 gence Applications on Wall St., Oct. 
9-11, New York City. Sponsor: Polytechnic 
Univ., Brooklyn. Contact Mary Bianchi, Poly¬ 
technic Univ., 333 Jay St., Brooklyn NY 
11201, phone (718) 260-3360, fax (718) 260- 
3136. 

Int’I Workshop on Visual Languages, 
Oct. 9-11, Kobe, Japan. Cosponsors: 
Hiroshima Univ., Univ. of Pittsburgh. Contact 
Shi-Kuo Chang, Computer Science Dept., 
Univ. of Pittsburgh, Pittsburgh, PA 15260, 
phone (412) 624-8423, fax (412) 624-8465. 

Workshop on Experimental Distrib- 
uted Systems, Oct. 12, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, 1 Space Park, 
DH2/2328, Redondo Beach, CA 90278, phone 
(213) 764-6033. 

/ijjj) RIDT 91, Second Int’I Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 14-15, Boston. Cosponsor: Univ. of 
Massachusetts. Contact Robert A. Morris, 
Math, and Computer Science Dept., Univ. of 
Massachusetts at Boston, Harbor Campus, 
Boston, MA 02125-3393, phone (617) 287- 
6466, e-mail ridt91-request@cs.umb.edu. 

ICCD 91, IEEE Int’I Conf. Symp. on 
Computer Design, Oct. 14-16, Cam¬ 
bridge, Mass. Cosponsors: IEEE Computer 
Soc. and IEEE Circuits and Systems Soc. 
Contact ICCD 91, IEEE Computer Soc., 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 


16th Conf. on Local Computer Net- 
works, Oct. 14-17, Minneapolis, Minn. 
Cosponsor: IEEE Computer Soc. Technical 
Committee on Computer Comm. Contact 
James F. Mollenauer, Technical Strategy As- 
sociaes, 37 Silver Birch Rd., Newton, MA 
02168, phone and fax (617) 244-0077. 

Conf. on Software Maintenance, Oct. 
14-17, Sorrento, Italy. Cosponsor: 

IEEE. Contact Vaclav Rajlich, Computer Sci¬ 
ence Dept., Wayne State Univ., Detroit, MI 
48202, phone (313) 577-5423, fax (313) 577- 
6868, e-mail vtr@cs.wayne.edu; John Mun¬ 
son, Computer Science Dept., Univ. of West 
Florida, Pensacola, FL 32514; or Malcolm 
Munro, Centre for Software Maintenance, 
Univ. of Durham, Durham, DH1 3LE, 
England, phone 44 (091) 374-2634, e-mail 
malcolm. munro@uk.ac.durham. 

Int’I Workshop on Object Orienta¬ 
ls^ tion in Operating Systems, Oct. 17-18, 

Palo Alto, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating Sys¬ 
tems. Contact Vincent Russo, Computer Sci¬ 
ence Dept., Purdue Univ., West Lafayette, IN 
47907, phone (317) 494-6008, fax (317) 494- 
0737. 

Visualization 91, Oct. 22-25, San 
Diego, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Computer 
Graphics. Contact Bruce Brown, Oracle, 500 
Oracle Pkwy., MD 40P12, Redwood Shores, 
CA 94065, phone (415) 726-0983, fax (415) 
506-7200; or Gregory M. Nielson, Computer 
Science Dept., Arizona State Univ., Rural 
Road and University, Tempe, AZ 85287-5406, 
phone (602) 965-2785. 

|£j^j Sixth Int’I Workshop on Software 
Specification and Design, Oct. 25-26, 

Como, Italy. Contact C. Ghezzi, Dip. di 
Elettronica, Politecnico di Milano, Piazza Le¬ 
onardo Da Vinci 32, 20133 Milano, Italia, 
e-mail relett24@imipoli.bitnet; or Jean-Pierre 
Finance, CRIN, Campus Scientifique, BP239, 
54000 Nancy, France. 

® ILPS 91, Int’I Logic Programming 
Symp., Oct. 28-31, San Diego, Calif. 
Sponsor: Assoc, of Logic Programming. Con¬ 
tact Kenneth Kahn or Vijay Saraswat, Xerox 
PARC, 3333 Coyote Hill Rd., Palo Alto, CA 
94304, Kahn’s phone (415) 494-4390, Saras- 
wat’s phone (415) 494-4747, fax (415) 494- 
4334, e-mail ilps91@parc.xerox.com. 

® ITC 91, Int’I Test Conf., Oct. 28-Nov. 

1, Nashville, Tenn. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Thomas, 
PO Box 264, Mt. Freedom, NJ 07970, phone 
(201) 895-5260, fax (201) 896-7265; or IEEE 
Computer Soc., 1730 Massachusetts Ave. 

NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 

ISCIS VI, Sixth Int’I Symp. on Com- 
VS? puter and Information Sciences, Oct. 
30-Nov. 2, Ankara, Turkey. Sponsor: Bilkent 
Univ., IEEE Turkey Chapter. Contact Mehmet 
Baray, Bilkent Univ., Computer Eng. and In¬ 
formation Sciences Dept., Bilkent 06533 An¬ 
kara, Turkey, phone (90) 4-266-4133, fax 90 
(4) 266-4127, e-mail iscis@trbilun.bitnet. 
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November 1991 

g^ 25th Asilomar Conf. on Signals, Sys- 
v*7 terns, and Computers, Nov. 4-6, Pacif¬ 
ic Grove, Calif. Sponsors: Naval Postgraduate 
School, San Jose State Univ. Contact Frederic 
J. Harris, Electrical and Computer Eng. Dept., 
San Diego State Univ., San Diego, CA 92182- 
0190, (619) 594-6162. 

gi) TAI 91, Third IEEE Computer Soc. 
vK7 Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 5-8, San Jose, Calif. Contact 
Benjamin Wah, Coordinated Science Lab, MC 
228, Univ. of Illinois, 1101 W. Springfield 
Ave., Urbana, IL 61801-3082, phone (217) 
333-3516, fax (217) 244-1764, e-mail 
wah%aquinas@cso.uicu.edu; or Nikolaus G. 
Bourbakis, 4138 Moonflower Ct., San Jose, 
CA 95135, phone (408) 270-3455. 

/g^v Conf. on Organizational Computing 
Systems, Nov. 5-8, Atlanta. Sponsors: 
IEEE Computer Soc. Technical Committee on 
Office Automation, ACM SIGOIS, Int’l Fed¬ 
eration for Information Processing. Contact 
Frederick H. Lochovsky, Hong Kong Univ. of 
Science and Tech., Computer Science Dept., 
5/F World Shipping Center, 7 Canton Rd., 
Hong Kong, phone (852) 302-1642, fax (852) 
736-8801. 

gi) ICCAD 91, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 11-14, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Soc. Contact ICCAD 91 Secretary, 
MP Associates, 7490 Clubhouse Rd., Suite 
102, Boulder, CO 80301, phone (303) 530- 
4562. 

g^ Micro 24, 24th ACM/IEEE Int’l 
V57 Symp. and Workshop on Microarchi¬ 
tecture, Nov. 18-20, Albuquerque, N.M. Con¬ 
tact Yashwant K. Malaiya, Computer Science 
Dept., Colorado State Univ., Fort Collins, CO 
80523, phone (303) 491-7031, fax (303) 491- 
2293, e-mail malaiya@ravi.cs.colostate.edu. 

g^ | Supercomputing 91, Nov. 18-22, Albu- 
querque, N.M. Cosponsor: ACM. Con¬ 
tact Raymond L. Elliott, Computing and 
Comm. Div., MS B260, Los Alamos Nat’l 
Lab, Los Alamos, NM 87545, phone (505) 
667-1449, fax (505) 665-4361, e-mail 
rle@lanl.gov; or Supercomputing 91, IEEE 
Computer Soc., 1730 Massachusetts Ave. 

NW, Washington, DC 20036-1903, phone 
(202) 371-1013. 


gii 12th IEEE Symp. on Real-Time Sys- 
V&7 terns, Dec. 3-6, San Antonio, Texas. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. Contact 
Jane S.W. Liu, Computer Science Dept, Univ. 
of Illinois, 1304 W. Springfield Ave., Urbana, 
IL 61801, phone (217) 333-0135, e-mail 
janeliu@cs.uiuc.edu. 


gjj Compcon Spring 92, Feb. 24-28, San- 
Francisco. Contact Compcon Spring 92, 
IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


® Int’l Conf. on Parallel and Distri¬ 
buted Information Systems, Dec. 4-6, 

Miami Beach, Fla. Cosponsors: IEEE Com- March 1992 
puter Soc. et al. Contact Amit Sheth, Bellcore, 

1J-210, 444 Hoes Ln„ Piscataway, NJ 08854, 
phone (908) 699-3300, fax (908) 699-9011, 
e-mail amit@ctt.bellcore.com. 


gi) 1991 Winter Simulation Conf., Dec. 
N57 8-11, Phoenix, Ariz. Sponsor: ACM. 
Contact Robert Crain, Wolverine Software, 
4115 Annandale Rd., Suite 200, Annandale, 
VA 22003. 

g^j World Congress on Expert Systems, 
VS7 Dec. 16-19, Orlando, Fla. Cosponsors: 
Int’l Assoc, of Knowledge Engineers et al. 
Contact World Congress on Expert Systems, 
c/o Congress Secretariat, Congrex (USA), 

Inc., 7315 Wisconsin Ave., Suite 404E, Be- 
thesda, MD 20814, phone (301) 469-3355, fax 
(301) 469-3360. 


January 1992 


December 1991 

® Third IEEE Int’l Symp. on Parallel 
and Distributed Processing, Dec. 1-5, 

Dallas. Sponsors: IEEE Computer Soc., IEEE 
Dallas Section, ACM SIGArch. Contact Sartaj 
Sahni, CIS Dept., CSE 301, Univ. of Florida, 
Gainesville, FL 32611, phone (904) 392-1527, 
fax (904) 392-1220; or Behrooz Shirazi, Univ. 
of Texas at Arlington, Computer Science Eng. 
Dept., Box 19015, Arlington, TX 76019-0015, 
phone (817) 273-3605, fax (817) 273-2548, 
e-mail shirazi@evax.utarl.edu. 


February 1991 

g^< Eighth Int’l Conf. and Workshop on 
Data Eng., Feb. 1-7, Phoenix, Ariz. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Data Eng. Contact (for the con¬ 
ference) Nick J. Cercone, Center for Systems 
Sciences, Simon Fraser Univ., Burnaby, B.C., 
Canada V5A 1S6, phone (604) 291-3229, 
e-mail nick@cs.sfu.ca; or (for the workshop 
on research issues) Clement Yu, Electrical 
Eng. and Computer Science Dept., Univ. of 


gvi Fourth Int’l Conf. on Strategic Soft- 
v*7 ware Systems, Mar. 10-11, Huntsville, 
Ala. Cosponsors: IEEE Computer Soc. Hunts¬ 
ville Chapter, Univ. of Alabama in Huntsville. 
Contact Ann H. Yelle, Univ. of Alabama in 
Huntsville, Continuing Education Division, 
Conferences (SSS-92), Bevill Center 289-A, 
Huntsville, Al 35899, phone (800) 448-4035 
or (205) 895-6372, fax (205) 895-6760. 

g^ Int’l Symp. on Parallel Processing, 
\*7 Mar. 30-Apr. 2, Beverly Hills, Calif. 
Contact Larry H. Canter, Computer Systems 
Approach, 1140 S. Raymond Ave., Suite B, 
Fullerton, CA 92631, phone (714) 738-3414, 
fax (714) 738-3470. 


April 1992 


© Fifth Int’l Conf. on VLSI Design, Jan. 

4-7, Bangalore, India. Sponsor: VLSI 
Soc. of India et al. Contact A. Laha, Cadence 
Design Systems, Systems Division, 2 Lowell 
Research Center Dr., Lowell, MA 01852- 
4995, phone (508) 934-0233; or L.M. Patnaik, 
Microprocessor Applications Lab, Indian Inst, 
of Science, Bangalore, 560012, India, phone 
91 (812)342-451. 

g^j Hawaii Int’l Conf. on Systems Sci- 
ences, Jan. 7-10, Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Contact Luqi, Comput¬ 
er Science Dept, Naval Postgraduate School, 
Monterey, CA 93940, phone (408) 646-2468. 

gi) IEEE Int’l Conf. on Wafer-Scale In- 
tegration, Jan. 22-24, San Francisco. 
Sponsors: IEEE Computer Soc., IEEE Compo¬ 
nents, Hybrids, and Manufacturing Tech. Soc. 
Contact Peter W. Wyatt, MIT Lincoln Lab, B- 
153, Box 73, Lexington, MA 02173-9108, 
phone (617) 981-7232. 


gvt Third Workshop on Workstation Op- 
ns7 erating Systems, Apr. 23-24. Sponsor: 
IEEE Computer Soc. Technical Committee on 
Operating Systems. Contact Joseph Boykin, 
Encore Computer, 257 Cedar Hill St., Marl¬ 
borough, MA 01752, phone (508) 460-0500, 
fax (508) 485-0709. 


May 1992 

g jj j) IEEE Infocom 92,11th Conf. on 
v»7 Computer Comm., May 4-8, Florence, 
Italy. Cosponsor: IEEE Comm. Soc. Contact 
L. Fratta, Politecnico di Milano, c/o Cefriel, 
Via Emanueli, 15, 20126 Milano, Italy, phone 
39 (2) 2399-3578, fax 39 (2) 2399-3587, e- 
mail fratta@imicefr.bitnet; or J. Kurose, Com¬ 
puter and Information Science Dept., Univ. of 
Massachusetts, Amherst, MA 01003, phone 
(413) 545-1585, e-mail kurose@cs.umass.edu. 

gj\ Comp Euro 92, IEEE Int’l Conf. on 
V57 Advanced Computer Tech., Reliable 
Systems, and Applications, May 4-8, the 

Hague, the Netherlands. Cosponsors: IEEE 
Region 8, IEEE Benelux. Contact G.J. Arink, 
Philips Medical Systems, PO Box 10.000, 
5680 DA Best, the Netherlands, phone 31 (40) 
762-060. 

gjj) ICSE 92, 14th Int’l Conf. on Software 
v£ 7 Eng., May 11-15, Melbourne, Austra¬ 
lia. Cosponsors: IEEE Computer Soc. et al. 
Contact A.Y. Montgomery, Computer Science 
Dept., Royal Melbourne Inst, of Tech., PO 
Box 2476V, Melbourne 3001, Victoria, Aus¬ 
tralia, phone 61 (3) 660-2943, fax 61 (3) 662- 
1617, e-mail aym@goanna.cs.rmit.oz.au. 
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CAREER OPPORTUNITIES 


RATES: $ 12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, 
Los Alamitos, CA 90720-1264; (714) 
821-8380; fax (714) 821-4010. 


POSITION WANTED 


PROGRAMMING 

Want full-time programming job. Ph.D. in 
math. MS in CS. 5 years programming ex¬ 
perience. Wide variety of projects. Many 
computer languages. Good at writing, inter¬ 
viewing users, making presentations to 
customer. Prefer Los Angeles area. Robert 
Park. 5862 1/2 W. 88th St.. Los Angeles. 
CA 90045. (213) 645-4091. 



WASHINGTON UNIVERSITY 

Washington University in St. Louis seeks 
qualified candidates for the position of Pro¬ 
fessor and Chair of the Department of Com¬ 
puter Science, with a desired starting date of 
July 1, 1991. We are interested in candi¬ 
dates with a strong research record, with a 
dedication to excellence in undergraduate 
and graduate education and with a demon¬ 
strated potential for administration and 
leadership. 

The Department has an excellent under¬ 
graduate program as well as a strong and ex¬ 
panding graduate program. The primary re¬ 
search concentrations are in distributed 
systems, advanced communication networks 
and intelligent computer systems with an 
emphasis on visualization as a tool in each 
case. The Department plans to continue 
building on these areas of strength as well as 
expanding into new areas. There are 15 
regular faculty in the Department and 85 
graduate students, as well as an excellent 
technical support staff and a large pool of af¬ 
filiate faculty. Departmental laboratory 
facilities are very good and include a visuali¬ 
zation laboratory, a systems prototyping lab, 
an NCUBE parallel computer, a variety of 
compute servers and ubiquitous workstations. 

Washington University has a longstanding 
commitment to the principle that all can¬ 
didates should be afforded equal opportuni¬ 
ty regardless of age, race, sex or physical 
disability. Candidates must send a cur¬ 
riculum vitae and a list of references to: Pro¬ 
fessor C.I. Byrnes, Search Committee for 
the Computer Science Chair, Campus Box 
1040, Washington University, One Brook¬ 
ings Drive, St. Louis, MO 63130. 


UNIVERSITY OF UTAH 
DEPARTMENT OF 
COMPUTER SCIENCE 

Applications are invited for a tenure-track 
position in Computer Science, available in 
September 1991. One position is in the area 
of Systems and the other in Robotics/Com¬ 
puter Vision. All applicants should have a 
PhD in Computer Science. A strong com¬ 
mitment to research and teaching is re¬ 
quired . Send CV and names of at least three 
references to: Faculty Recruiting Commit¬ 
tee, Department of Computer Science, 
3190 MEB, University of Utah, Salt Lake 
City, Ethan 84112. The University of Utah is 
an Equal Opportunity, Affirmative Action 
Employer and encourages nomination and 
applications from women and minorities. 


ASIAN INSTITUTE OF 
TECHNOLOGY (AIT) 

The Division of Computer Science invites 
applications for long term and visiting faculty 
positions, particularly in information systems 
and software engineering. Applicants should 
haveaPh.D. in Computer Science or closely 
related fields. Duties include research, 
teaching and supervising graduate students. 
Rank and salary commensurate with experi¬ 
ence and qualification; local Thai taxes are 
paid by AIT. 

AIT is an autonomous, non-profit gradu¬ 
ate school supported internationally and 
located near Bangkok. Bangkok is rapidly 
growing into a commercial and cultural hub 
of Asia. The Institute offers a good research 
environment. Facilities include super-mini- 
computers, SUN and SONY NEWS work¬ 
stations, MAC-II as well as PCs, all networked 
and world-wide connection available. 

Applications will be considered as received 
and recruiting will continue until all positions 
are filled. Applicants should send a resume, 
a transcript and the names of three refer¬ 
ences to: Vice President for Academic Af¬ 
fairs, AIT, P.O. Box 2754, Bangkok 10501, 
Thailand (vw@ait.th). 


UNIVERSITY OF GUAM 
Division of Mathematical Sciences 

The University of Guam solicits applica¬ 
tions for the following tenure track position: 

INSTRUCTOR TO ASSOCIATE 
PROFESSOR OF COMPUTER SCIENCE 
Candidates must have at least a Master's 
Degree in Computer Science with teaching 
experience at the tertiary level. Preference 
will be given to candidates with an earned 
Ph.D. in Computer Science. The successful 
candidate must have a strong commitment 
to quality teaching of both remedial students 
in mathematics and college level student in 
mathematics and computer science, and a 
demonstrated interest in the development of 
a new degree program in computer science. 
Applicant must be a U.S. citizen or perma¬ 


nent resident prior to employment. Rank 
and salary commensurate with qualifications 
and experience. 

Salary: Instructor $30.541-$44.481 per 
academic year. Assistant Professor $33,634- 
$49,770 per academic year. Associate Pro¬ 
fessor $38.529-$58.144 per academic year. 

Requests for official application forms and 
other information may be directed to the 
Personnel Services Division. UOG Station. 
Mangilao. Guam. 96923. Send completed 
application forms, updated resume or cur¬ 
riculum vitae, official graduate transcripts 
(sent directly from^awarding institution/s), 
copies of undergraduate transcripts, three 
letters of reference or placement file to: 

Dr. Henry J. Taijeron. Chair 
Computer Science Search Committee 
C/O Personnel Services Division 
UOG Station. Mangilao. Guam 96923 
The selection process will begin April 15. 
1991, and continue until the position is filled. 
EEO/AAE. 


UNIVERSITY OF 
WISCONSIN-MADISON 
Faculty Position 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
a possible tenure or tenure-track position. 
A Ph.D. degree is required, and successful 
candidates are expected to participate in 
both teaching and research activities. Ap¬ 
plicants in all areas of computer engineering 
are invited to apply. Rank and salary will be 
commensurate with qualifications and ex¬ 
perience. Send resume and names of three 
references to Bahaa E.A. Saleh. Chairman. 
Department of Electrical and Computer 
Engineering. University of Wisconsin- 
Madison. 1415 Johnson Drive. Madison. 
WI53706. an equal opportunity/affirmative 
action employer. 


KNOX COLLEGE 
Department of Mathematics and 
Computer Science 
Galesburg, IL 61401 

One year position at the instructor or assis¬ 
tant level beginning Sept. 91. Expect tenure 
track position for 1992-93. Candidates must 
have an M.S. (Ph.D. preferred) in Compu¬ 
ter Science and a commitment to excellence 
in teaching and continued scholarly develop¬ 
ment. Ability to teach a broad range of de¬ 
partmental offerings is desirable. All fields 
considered. Salary is competitive. Teaching 
load is two courses per term for each of three 
terms. Send letter of application, resume, 
graduate transcript, and three letters of 
recommendation to Dennis M. Schneider. 
Chair. 

Knox College is a highly selective liberal 
arts institution of about 1000 students. The 
college is an EO/AA employer: it particu¬ 
larly invites applications from women and 
minority candidates. 
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ENDOWED CHAIR IN ELECTRICAL 
ENGINEERING 
AT GEORGIA TECH 

The Georgia Institute of Technology is 
seeking candidates for the Joseph M. Pettit 
Chair in the School of Electrical Engineering. 
Applications and nominations for this en¬ 
dowed chair are now being accepted. It is ex¬ 
pected that the chair holder will play a prin¬ 
cipal role in the definition and development 
of future programs in the area of computer 
engineering and/or closely related areas. 
Candidates must have a record of distin¬ 
guished performance and well established 
potential for providing leadership in research 
and instructional program development. 
Salary and program development funds avail¬ 
able for support of this distinguished position 
are fully competitive. Resumes and nomina¬ 
tions should be submitted by September 2, 
1991 and addressed to: 

Director 

School of Electrical Engineering 
Georgia Institute of Technology 
Atlanta, GA 30332-0250 
Georgia Tech is an equal opportunity, affir¬ 
mative action employer. 


CENTER FOR AEROSPACE SCIENCES 
Associate /Assistant Dean 

The University of North Dakota invites ap¬ 
plications for an anticipated opening as 
Associate/Assistant Dean at the Center for 
Aerospace Sciences. 

The Center for Aerospace Sciences is the 
second largest degree granting college within 
the University and includes the Departments 
of Aviation, Atmospheric Sciences, Compu¬ 
ter Science and Space Studies as well as the 
Divisions of Flight Operations and Computer 
Services. 

This position is a vital part of the Dean’s of¬ 
fice and has primary responsibility for the 
academic leadership to the faculty, staff and 
students of the college in all aspects of re¬ 
search, teaching and service. The Associate/ 
Assistant Dean also contributes to the main¬ 
taining of effective relationships with state 
and federal agencies, with state and regional 
educational institutions, and with corporate 
and other organizations which may provide 
possibilities for program research and service 
activities. 

Candidates must have scholarly accom¬ 
plishment and breadth of interests, com¬ 
mitment to high academic standards, and 
proven administrative ability. Academic 
qualifications, including earned doctorate in 
an appropriate field, should meet customary 
expectations for appointment as full or 
associate professor. Administrative title 
dependent upon administrative experience 
in an academic setting. 

This is a 12 month appointment, possibly 
tenure-eligible. with an anticipated starting 
date of September 1, 1991. Salary is com¬ 
petitive and commensurate with experience 
and qualifications. 

Send letter of application and resume to 
Chair. Associate/Assistant Dean Search 
Committee. Center for Aerospace Sciences, 
Box 8216 University Station, Grand Forks, 
ND 58202-8216. 

The University of North Dakota is an Affir¬ 
mative Action, Equal Opportunity Employer. 


RESEARCH SCIENTIST 

Senior member of the technical staff work¬ 
ing in the capacity of a research scientist 
performing research and development to 
advance the state-of-the-art in artificial in¬ 
telligence and software engineering, to apply 
artificial intelligence techniques in telecom¬ 
munications and business, to develop var¬ 
ious software engineering environments. 
CASE tools, and computer networking facili¬ 
ties for super-computers, workstations, and 
personal computers by incorporating artifi¬ 
cial intelligence techniques, utilizing 
knowledge of object-oriented technology 
and programming in both CLOS and C + + . 
providing current and future trends in soft¬ 
ware development technology, software 
process assessment, communicating verbally 
with technical staff, and writing advanced 
research papers, reports, and technology 
surveys. Requires Ph D. degree in Electrical 
Engineering and five years of experience 
doing research and development in artificial 
intelligence. $65,000 per annum. 40 hours 
per week. 

Apply at the Texas Employment Commis¬ 
sion. Irving. Texas, or send resume to the 
Texas Employment Commission. TEC Build¬ 
ing, Austin. Texas 78778. J.O. *6344368. 
Ad Paid by an Equal Employment Oppor¬ 
tunity Employer. 


SOFTWARE ENGINEER 

Work with team creating next generation 
development environment for real-time ex¬ 
pert systems. Perform primary coding for 
project, learn internals of proprietary 
operating system and serve as in-house tech¬ 
nical resource. Strong engineering and CS 
background. C, 6502 assembly, prior Mac 
application development experience re¬ 
quired. 

UMECORP is an AI firm offering the flex¬ 
ibility of a small company with the excite¬ 
ment of a growing start-up environment. 
Benefits include medical/dental and strong 
stock incentives. Send resume and salary 
history to: 

Personnel Manager 
UMECORP 

73 Digital Dr., MS/IC591 
Novato, CA 94949 


UNIVERSITE CATHOLIQUE 
DE LOUVAIN 
BELGIUM 

School of Management 
(Institut d’Administration et de 
Gestion) 

The Universite Catholique de Louvain in¬ 
vites applications for a tenure-track faculty 
position in the School,of Management 
(Field: Information Systems) to be filled by 
October 1. 1991. Rank and salary depend 
upon qualifications arid experience. 
Responsibilities include research, supervi¬ 
sion of graduate students research. participa¬ 
tion in the management of research projects, 
teaching in various study programs both at 
the graduate and undergraduate levels. 

Candidates should have a Ph. D. degree in 
the field of informafion systems and a com¬ 


mitment to excellence in both research and 
teaching: leadership skills are highly valued. 
A working knowledge of French is required. 

Preference will be given to candidates with 
experience in management information sys¬ 
tems. design and logic of data bases, expert 
systems and decision support systems. 

The School of Management of the Catho¬ 
lic University of Louvain is located in the new 
city of Louvain-la-Neuve. 30 km South of 
Brussels, the capital of Belgium, in the heart 
of Europe. 

Additional information may be obtained 
from Prof. F. Juckler. Institut d'Administra- 
tion et de Gestion. 16. Avenue de I'Espi- 
nette. B-1348 Louvain-la-Neuve, Belgium. 
(Phone: +32 1047 30 72. Fax: +321047 
30 24) 

A resume with full bibliography, a certified 
copy of the degree. one copy of the five most 
significant publications, a research plan for 
the next three years and the names of three 
references should be sent before May 27, 
1991 to: Prof. P. Macq, Recteur. UCL, 
Place de l'Universite. 1, B-1348 Louvain-la- 
Neuve, Belgium. 


RESEARCH (SOFTWARE) ENGINEER 

Conduct research and development of 
system software for microprocessor-based 
digital/analog medical instrumentation, 
critical patient care systems and networked 
clinical information management systems, as 
well as PC-based application software. 

Must have Master’s degree in Computer 
Science/Electrical Engineering plus one year 
of experience. The experience must include: 

1) Realtime embedded system in a multi¬ 
tasking operating system & multi¬ 
processor environment. 

2) Structured system analysis, design & 
documentation techniques, software 
architectural definition & specification 
for development of microprocessor- 
based highspeed data communica¬ 
tion, acquisition, & control software. 

3) Software design, implementation, 
test, integration, and validation, in¬ 
cluding use of Logic Analyzer, Oscillo¬ 
scope, Target System Emulator, 
Source/Machine Level Debugger, 
and PROM programmer. 

4) INTEL 8086 family assembly language 
and high order language programming 
in C or Pascal. 

5) PC-based software applications run¬ 
ning under MS-DOS and VAX VMS 
Operating Systems. 

6) Standard software development tools 
(PVCS, CASE, linker/locator, com¬ 
piler, assembler) & interactive com¬ 
puter graphics with human interface 
programming. 

In lieu of Master's degree plus one year of 
experience, must have Bachelor's degree in 
CS/EE plus minimum three years experi¬ 
ence in the above areas. 

Seattle area employer. Pay $37,500/yr. 
8 am to 5 pm. 40 hrs/wk. Must have proof 
of legal authority to work in the United 
States. 

By June 1, 1991 send resume to: WA. 
State Employment Security Dept., ES DIV. 
Job *245294-T, Olympia, WA 98054. 


May 1991 
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SYSTEMS ACCOUNTANT 

Design, develop and implement computer¬ 
ized database, accounting and financial sys¬ 
tem (s). Design develop, test and implement 
specialized accounting and time manage¬ 
ment systems including hybrid (mainframe 
and personal) computer network protocols 
to allow data transfers for diverse client base. 
Establish procedures and training related to 
these systems. Design and oversee develop¬ 
ment of secure automated backup system (s) 
for confidential and sensitive data, as well as 
security safeguards for programs. Manage 
multiple projects by directing in-house com¬ 
puter and financial staff as well as oversee ac¬ 
counting matters involving offsite computer 
staff or contractors. Administer policies, 
procedures and systems to monitor business 
activities including developing profitability in¬ 
formation and management reports and utili¬ 
zation of financial analysis techniques such 
as discounted cash flow, lease/buy. project 
financing. $3000 /mo. 40hr/wk. Bachelors 
in Accounting. Requires 3 years in Job Of¬ 
fered or 3 years in position involving account¬ 
ing and related systems development, in¬ 
cluding spreadsheets, databases and main¬ 
frame. Compliance with nonsmoker, drug 
free policy. Submit resume and 3 reference 
letters in person or by mail to Texas Employ¬ 
ment Commission. TEC Building. Austin. 
Texas 78778. J.O. #6139069. Ad Paid By 
Equal Employment Opportunity Employer. 


RESEARCH CHAIR IN 
HIGH-SPEED NETWORKS 
Department of Electrical Engineering 
University of Ottawa, Canada 

The Ottawa Carleton Research Institute 
(OCRI), the Natural Sciences and Engineer¬ 
ing Research Council of Canada (NSERC), 
the Telecommunications Research Institute 
of Ontario (TRIO), and the following 
companies 

BNR. 

Bell Canada 

Digital Equipment of Canada Ltd ., 
are sponsoring the $1.2 million 
OCRI/NSERC Industrial Research Chair 

High-Speed Networking Systems Architecture 
Ottawa is Canada’s capital and is often 
referred to as “Telecom Valley”, because of 
the large concentration of telecommunica¬ 
tions companies, led by BNR. This Chair is 
one of six (6) sponsored by OCRI in the Ot¬ 
tawa area and is aimed at enhancing the re¬ 
search excellence in the two local Univer¬ 
sities and their interaction with industry. The 
position is a tenure-track one. The successful 
candidate will be appointed at the full Pro¬ 
fessor level in the department of Electrical 
Engineering at the University of Ottawa, a 
major bilingual University in Canada and a 
principal partner in two Centers of Excel¬ 
lence, the Telecommunications Research In¬ 
stitute of Ontario (TRIO) and the Canadian 
Institute for Telecommunications Research 
(CITR). The Department of Electrical Engi¬ 
neering has currently 24 full-time professors, 
including 2 Research Chairs, 9 adjunct pro¬ 
fessors, 120 graduate students, 400 under¬ 
graduate students and annual research fund¬ 


ing exceeding $4.5 million. The Chairholder 
will interact with the Photonic Networks and 
Multimedia Communipations Research 
Groups of the department, currently com¬ 
posed of more than 50 researchers, funded 
at an annual rate of $2 million and carrying 
leading-edge research in the area. The Chair 
award includes funding for one research as¬ 
sociate, two graduate students, two co-op 
technicians and equipment. Extensive 
Photonic and Multimedia Communications 
laboratories are available. The Chairholder 
and the research team will interact with the 
industrial sponsors of the Chair. The Chair¬ 
holder will have reduced teaching load. 

REQUIREMENTS: Candidates should 
have a Ph.D. in Electrical or Computer 
Engineering. Experience in research and 
development of High-speed Networking 
Systems, Communications Networks and 
Network Protocols is required. The can¬ 
didate should have at least five years ex¬ 
perience in or with an industrial environment 
and have successfully conducted, as a group 
leader, advanced research and development 
projects in the above domain. The candidate 
should present evidence of scientific produc¬ 
tivity and quality either through refereed 
publications or other indicators more ap¬ 
propriate to an industrial background (e.g. 
patents, technical reports etc.) Interest in 
training graduate students and researchers 
and ability to work in a team and provide 
leadership are mandatory. Employment 
equity is a University policy. In accordance 
with Canadian Immigration laws, priority will 
be given to Canadian Citizens or permanent 
residents. 

Applications, including a detailed cur¬ 
riculum vitae and names of three references 
should be sent to: 

The Chairman 

Department of Electrical Engineering 
University of Ottawa 

Ottawa, Ontario, Canada, K1N-6N5 
Tel. +1-(613)-564-2495 
Fax: +1-(613)-564-6882 


UNIVERSITY OF VICTORIA 
Department of Electrical and 
Computer Engineering 
Faculty Position 

Applications are invited for a tenure-track 
position in the area of Computer Engineering 
in the Department of Electrical and Computer 
Engineering at the University of Victoria. 
The position will involve undergraduate and 
graduate teaching, graduate supervision at 
the master’s and doctoral levels, and re¬ 
search. We seek applicants who can add to 
our existing strengths in parallel and distri¬ 
buted systems, systems and applications, 
VLSI systems design, or in related areas of 
computer engineering. 

Applicants should hold a doctorate. In¬ 
dustrial experience and registration as a Pro¬ 
fessional Engineer in Canada will be con¬ 
sidered as assets. 

The Department of Electrical and Compu¬ 
ter Engineering at the University of Victoria 
was established on July 1. 1983 and is housed 
in attractive new buildings. The Department 
offers accredited undergraduate programs 
leading to the B.Eng. degrees in electrical 


engineering and computer engineering, and 
graduate programs leading to the M.Eng.. 
M.A.Sc., and Ph.D. degrees. The Depart¬ 
ment is very active in research with an an¬ 
nua] research budget in excess of 1.8 M$. 
The departmental facilities include over 30 
SUN workstations interconnected via ether- 
net. and modern equipment for research in 
computer engineering. These include several 
expert system development environments, 
design and testing facilities for VLSI and gate 
arrays, as well as facilities for research in 
neural networks and image processing. The 
Department participates in all three national 
Networks of Centres of Excellence in engi¬ 
neering. The faculty strength has recently in¬ 
creased to 18 full-time members. 

Victoria is situated at the southeastern tip 
of Vancouver Island and is well known for its 
superb climate and flqwers. 

In accordance with Canadian immigration 
regulations, this advertisement is directed to 
Canadian citizens and permanent residents 
of Canada. If no suitable candidates are 
found, the search may be extended to other 
candidates. The University of Victoria is 
committed to an employment equity plan. 
Women are especially encouraged to apply. 

Applications, which should include a cur¬ 
riculum vitae and the names of at least four 
referees, should be addressed to: 

. Chair 

Dept, of Electrical and 
Computer Engineering 
University of Victoria 
P.O. Box 3055 
Victoria, B.C. 

Canada V8W 3P6 


SOFTWARE ENGINEER 

By May 30, 1991, send resume to: 

Employment Security Department 
ES Division, Job # 247866-M 
Olympia, WA 98504 
JOB DESCRIPTION: Design and imple¬ 
ment data import and export mechanisms 
which are compatible with international ver¬ 
sions of word processing software packages 
utilizing “C" program language with Apple 
Macintosh and IBM PC-compatible micro¬ 
computers and Microsoft Windows version 
2.x operating environment. Design and im¬ 
plement character composition software to 
permit vertical text “flow” (as opposed to 
standard left-to-right text flow of English.) 
Implement software changes on existing 
software desktop publishing products. Con¬ 
vert and adapt existing software to support 
requirements for Japanese language. 

REQUIREMENTS: B.A. or B.S. in Math¬ 
ematics, Physics, Computer Science or 
Engineering. Must have six months software 
development experience utilizing “C” pro¬ 
gramming language and either Apple Macin¬ 
tosh or IBM PC-compatible microcomputer 
with the Microsoft Windows 2.x operating 
environment. Must fluently read, write and 
speak Japanese including current colloquial¬ 
isms. idioms and jargon, especially as per¬ 
tains to business usage. Must fluently read, 
write and speak English. Must have proof of 
legal authority to work in the U.S. 

SALARY RANGE: $29,000-$35.000/ 
annum. 40 hours/wk, 8AM-5PM, M-F. 
Position in Seattle. WA. EOE. 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 




BENEFITS 


Computer 

You automatically 
receive Computer with 
membership. Written, 
reviewed, and refereed 
by experts, it features 
survey and tutorial 
articles covering the 
entire computer field, 
and departments such 
as new products, pro¬ 
duct reviews, standards, 
and a reader forum 
called “The Open 
Channel." (monthly). 

Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books and Videos 

Receive discounts of up to 50% on over 700 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and visualization. Over 120 new products 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 


Schedule of Fees 


To join: see item 1, 2, or 3. 

To subscribe: see item 4. 

Membership dues and periodical subscriptions are annualized to, and expire on, 
December 31. Pay full- or half-year rate depending on date of receipt by the 
Computer Society as indicated below. Half Year Full Year 

Mar 1-Aug 31 Sept 1-Feb 28 

I I don’t belong to the IEEE and I want □ $27.00 □ $ 54.00 

to join just the Computer Society 

2 1 don’t belong to the IEEE and I want 

to join both the Computer Society and the IEEE* 

I reside in Region 1 -6 (United States). □ $52.50 □ $105.00 

I reside in Region 7 (Canada). □ $48.50 □ $ 97 

I reside in Region 8 (Europe, Africa, orthe Middle East) □ $48,00 □ $ 96 

I reside in Region 9 (Latin America). □ $44.50 □ $ 89 

I reside in Region 10 (Asia and Pacific). □ $43.50 □ $ 87 


ie Computer Society may deduct $5 off th 


3 1 already belong to the IEEE and I want 
to join the Computer Society 

IEEE Member Number 


□ $ 11.00 □$ 22 


I OPTIONAL PERIODICALS for new or current members 


IEEE Design and Test . 

IEEE Expert . 

IEEE Micro . 

IEEE Software . 

Transactions on: 

Computers . 

Knowledge and Data Engineering . 

Parallel and Distributed Systems ... 

Pattern Analysis and Machine Intelligence .12 

Software Engineering . 

Total amount remitted with this application $_ 

DC residents add sales tax to optional periodicals. 

□ Checks accepted in Belgian, British, German, Swiss, Japanese, or US currencies. 

Checks must be drawn on a bank in the country of origin of the currency. pR|CES EXp|R£ 12/31/gl 

□ Visa □ Master Card □ American Express Mo I Yr 

........ 111 rrt p 

Charge Card Number (Minimum Charge $10.) Exp. Date 


....6 

□ $12.00 

□ $ 

.... 4 

□ $11.00 

□ $ 

.6 

□ $10.00 

□ $ 

.6 

□ $10.50 

□ $ 

.6 

□ $12.50 

□ $ 

...12 

□ $12.00 

□ $ 

4 

□ $ 7.50 

□ $ 

.4 

□ $ 7.00 

□ $ 

...12 

□ $12.00 

□ $ 

...12 

□ $11.00 

□ $ 


ill be governed by IEEE’s and the society’s constitutions, bylaws, and statements of 


MAILING ADDRESS 


EDUCATION (highest level completed) 


ENDORSER (an iee 


Return to: IEEE Computer Society, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 USA. 

Residents of Europe mail to: IEEE Computer Society, 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. 

Asian/Pacific residents mail to: IEEE Computer Society, Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107 JAPAN. 


8888 18 | 88888 



















































BOOK REVIEWS 


Envisioning Information 

Edward Tufte (Graphics Press, Cheshire, Conn., 1990, 121 pp., $48) 


Edward Tufte again has illuminated us 
with his insight into the power of the vi¬ 
sual dimension of communicating infor¬ 
mation. His second work in this area, En¬ 
visioning Information, is as enlightening 
as his first book, The Visual Display of 
Quantitative Information. 

Tufte’s new book is a treatment and 
discussion of “cognitive art” or the de¬ 
sign of information. As such, it is partic¬ 
ularly relevant to today’s world where 
information abounds but ordered, inte¬ 
grated access to information does not. 
Particularly interesting and useful to to¬ 
day’s reader are his references, although 
sparse, to the problem of presenting in¬ 
formation on a computer screen; this of¬ 
fers greater challenges to the information 
designer than the printed page. 

The author’s treatment of information 
design is broadly based and includes ex¬ 
amples such as Galileo’s observations of 
sunspot activity, a New York/New Ha¬ 
ven train schedule, and various dance no¬ 
tations. He demonstrates that the visual 
dimension offers a vast channel for infor¬ 
mation communication but persuades us 
that it must be used very carefully to be 
effective. 

He sees the challenge to the informa¬ 
tion designer to be that of “escaping flat- 
land,” the two-dimensional surface, to 
represent complex, multidimensional in¬ 
formation. He says ^F.sqaping ... flatl and 
is the essential task of envisioning infor- 
rfiation — for all interesting worlds^ 
""(physical, biological, imaginary, human) 
that we seek to understand are inevitably 
and happily multivariate in nature.” 

A particularly interesting example of 
an attempt to escape flatland is a graphic 
timetable for a Java railroad line that was 
drawn in December 1937. The schedule 
shows a 24-hour railroad schedule 
through three-space and time with a doz¬ 
en other variables carried along, includ¬ 
ing a graphic profile of the valleys and 
mountains crossed by the rail and an 
aerial view of the network of tracks at 
each station. 

Tufte, throughout his book, admonishes 
the information designer to be aware of 
and avoid “chart junk." those marks (or 
noise) in the visual field that do not con¬ 


vey useful information and indeed, dis¬ 
tract from the information being presented. 

Another very interesting chapter fo¬ 
etuses on the richness of micro/macro de¬ 
sign Micro design is a design strategy 
that uses detail to present complexity. He 
states that complex information, effec¬ 
tively arranged, is very useful. This strat¬ 
egy is contrary to the admonishment that 
we are usually taught, the “keep it sim¬ 
ple” strategy. On the other hand, macro 
design is design without detail and com¬ 
plexity. Tufte shows the reader how both 
micro and macro design can be used to¬ 
gether effectively. 

The author illustrates this with a map 
of Manhattan by Constantine Anderson. 
This map, drawn in precise axonometric 
projection, in the macro dimension 
shows streets, intersections, etc., and al¬ 
lows us to navigate about. In its micro 
dimension, it shows the fine points, such 
as individual windows, subway stations 
and bus shelters, telephone booths, trees, 
and sidewalk planters. You can easily 
use this map. Having experienced the 
area on the map, you can relate to it on a 
personal level, allowing the user to bene¬ 
fit from detail as well as overview. Tufte 
insists that “clutter and confusion are 
failures of design, not the attributes of 
information” and advises us “to clarify, 
add detail.” 

One part of the book I particularly ap¬ 
preciated was the description of the Viet- 

n.mi \ i k-i.in- ....I in \\ .ishmclon. 

_DCjis-anexampleoFtEerise of micro/ 
macro design to achieve visual and emo¬ 
tional strength. On the mac roJcvel. the 
viewer approaches the wall, seeing it in 
its calm context. As you walk up to the 
wall, you see your own reflection and the 
reflections of nearby trees and shrubs. 

The names on the monument appear as a 
gray blur. OnJhejnieroXevel, the gray 
blur reveals the names ofjhe 58,000 
dead soldiers in tj yekjrd&rTn-wIucTTthey 
died, telling a story of sorts about thej n- 
sWceiSEtheiFdeatinTuftecarefuiryTe- 
veals here the~sfrength of the micro/mac¬ 
ro design strategy. 

Another interesting chapter presents 
the technique of small multiples — the 
use of multiple images of a changing ob¬ 


ject forces the viewer to compare images. 
Similarly, this technique can be used to 
represent dissimilar images, forcing the 
reader to discern the dissimilarities. 

Tufte discusses the struggle between the 
maintenance of context and the enforce¬ 
ment of comparison and demonstrates 
this struggle with a topographic diagram 
of the world’s longest rivers as if they 
had been straightened out and laid side 
by side in length order on the diagram. In 
the macro sense, this diagram looks like 
a bar chart, allowing one to easily com¬ 
pare the length of the Nile with the 
length of the Amazon. On a micro level, 
the context is preserved because each 
river is represented in a realistic way be¬ 
cause the diagram includes notations of 
the cities that border each river and its 
tributaries. Thus, context and the en¬ 
forcement of comparison are presented in 
the scope of the eyespan, and informa¬ 
tion is conveyed visually. 

Since more and more of us have the 
advantage of co lor workstations a t our 
fingertips, the most practical chapter in 
the book is the chapter on color and in¬ 
formation. In this chapter, Tufte explores 
how c olor can be used to enhance the de ¬ 
si gn ofTnl ormation. He illustrates Oliver 
Byrne's pUrriraTafly good use of color in 
his 1847 edition of Euclid’s Geometry. 
Byrne discarded the traditional geometric 
letter coding (for example, denoting an 
angle as ABC) and replaced it with color 
coding, presenting proofs in an easily un¬ 
derstood, effective way. 

Tufte points out that the computer dis¬ 
play is the interface between two infor¬ 
mation processing entities, the human 
and the computer. However, the common 
display devices are low-resolution, nar¬ 
row-band terminals that choke off fast, 
precise, and complex communications. 

He suggests that we can use color to im¬ 
prove the information resolution of the 
screen and suggests ways that a screen 
designer might proceed — for example, 
softening the background while using 
color to define the edges of the windows 
and to degrid the design to reduce noise. 
Used in this way, he claims that color is 
both subtle and exacting. 

I highly recommend this book to anyone 
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who is interested in the concept of infor¬ 
mation design. For those who wish to read 
further, the references provide a good be¬ 
ginning. The book itself is attractively 
done. The illustrations are very interesting 
and seem to support Tufte’s points, al¬ 


though they are sometimes difficult to 
completely understand. Also, I found it 
difficult to connect the illustrations to the 
text that explained them. It was annoying 
when, without notice, the author shifted 
from discussing one illustration to discuss¬ 


ing another. Overall, though, the book was 
a joy to read. 


Chris Comte 

Rochester Institute of Technology 


Algebraic Specifications in Software Engineering: An Introduction 

Ivo Van Horebeek and Johan Lewi (Springer-Verlag, Berlin, 1989, 350 pp., $35) 


I am a firm believer in integrating for¬ 
mal methods and software engineering, 
since I believe it’s important for software 
designers and programmers to under¬ 
stand the usefulness of formal specifica¬ 
tions (particularly in the early stages of 
software and systems development). 

Few people would argue with 
Horebeek and Lewi’s claim that for for¬ 
mal methods to gain wider acceptance in 
the scientific and engineering communi¬ 
ties, we need higher quality tools and 
better tutorial-level introductions. It 
should be emphasized that the primary 
goal of this book is to provide a “good 
introduction” to the field of algebraic 
specification. As a former software de¬ 
sign engineer familiar with formal speci¬ 
fication and verification methods, I have 
formulated my opinions in this review 
accordingly. 

In some ways, the authors attain their 
goal. The book conveys the importance of 
formal algebraic specification properties, 
such as consistency, completeness, com¬ 
pactness, and accuracy. The authors offer a 
variety of useful examples and convey the 
importance of constructive specification 
languages — languages that can be sym¬ 
bolically executed, enabling preimplemen¬ 
tation simulation and rapid prototyping. 
Languages that support rapid changes to 
specifications can be used to incorporate 
feedback (from the customer and from ear¬ 
ly simulation results) into the system in a 
timely fashion. 

Overall, though, the authors didn’t do 
a particularly good job of keeping the 
reader’s attention. From a software engi¬ 
neer’s point of view, creating an abstract 
formalism bears little relationship to the 
familiar software development process 
that designers are accustomed to dealing 
with. Terms like “many-sorted algebra,” 
“variable free-term language,” and 
“equational reasoning” would be far 
more meaningful to software engineers if 
a concrete association could be made to 
programming or software design. 

It would have been helpful to exploit 
the parallels between a collection of 
modern software design methodologies 
and formal algebraic design specifica¬ 
tion. There are many examples of Ada 
program development that would serve 
nicely here. 


If the authors could somehow relay 
their enthusiasm for the subject to the 
reader, they might strengthen their 
chances at “closing the gap between the¬ 
ory and practice by providing a good in¬ 
troduction.” While I share their positive 
outlook for the accelerated use of alge¬ 
braic (and other forms of) specification 
and formalization, I contend that readers 
should be left with a feeling of excite¬ 
ment about the subject — a hunger for 
the topic after putting the textbook down. 
This text did not elicit such a reaction 
from me. 

Although the authors cover both the 
algebraic language fundamentals and 
specification of a real-world private au¬ 
tomatic branch exchange (PABX) exam¬ 
ple, the book would profit greatly from 
some presentation changes. In particular, 
to make formal specifications more pal¬ 
atable to software design engineers and 
programmers, the algebraic specifica¬ 
tions could be accompanied by some 
high-order-language source code. This 
way, the more familiar representation 
(code) would contrast with the formal al¬ 
gebraic specifications. This would offer 
implementers the opportunity to visually 
connect the procedural and axiomatic 
representations. Without a solid point of 
reference, the intended audience won’t 
maintain an interest in the material. 

I was particularly frustrated with how 
the module listings were spread across 
several pages. While breaking listings is 
one of the unfortunate realities of includ¬ 
ing code or specification listings in text¬ 
books, the publisher/editor could have 
used better judgment about where to 
break them. (In fact, of the 78 instances 
where listings were broken, nine were 
across three or more pages; this makes 
the listings difficult to follow.) Further¬ 
more, I think the illustrations were mean¬ 
ingful, but they were amateurish and fell 
short of professional quality standards 
for textbook graphics. 

To help keep the reader’s attention, I 
would have introduced the related topic 
of software engineering tools and envi¬ 
ronments. This area is applicable to for¬ 
mal specification, since the number of 
automated systems is growing. These 
tools support at least some portion of the 
algebraic specification methodology de¬ 


tailed in the book, and sometimes a great 
deal more. Also, I would like to have 
seen more on automated tools for support 
for specification, verification, validation, 
simulation, modeling, and testing. One 
nice example that combines formal alge¬ 
braic specification with code develop¬ 
ment is ORA Corporation’s Penelope 
Ada Verification system, which supports 
Larch algebraic specifications (John Gut- 
tag, Jim Horning, and Jeanette 
Wing,“Larch in Five Easy Pieces,” Digi¬ 
tal Systems Research Center, Tech. Re¬ 
port 5, 1985). 

Formal methods may be making a 
comeback over the next few years in the 
computing sciences. There appears to be 
a resurgent interest in formal logic and 
mathematical rigor both here and 
throughout the European Community. 
Along with the need to produce high- 
assurance safety-critical software comes 
the need for good textbooks to introduce 
students to various forms of specification 
and verification. (The number of refer¬ 
ences to algebraic specification alone is 
steadily growing.) 

This book is intended for software en¬ 
gineers and programmers, but I believe 
the authors have misjudged their target 
audience. Introductory expositions do not 
need to fill an entire book; I recently 
read a short article entitled “Notes on Al¬ 
gebraic Specifications” by I. M. Bradley 
(Butterworth Scientific, 1989) that con¬ 
veyed a great deal of information in a 
modest eight pages. 

To be fair, despite the awkward pre¬ 
sentation, I can sincerely say that the ma¬ 
terial in this text appears to be well re¬ 
searched and accurate. Both authors have 
published extensively in this area for 
several years and are regarded as authori¬ 
ties on the subject. My main objection 
pertains to the packaging and presenta¬ 
tion of their work. I have difficulty see¬ 
ing how this text will “be of interest to 
software designers and programmers” as 
the authors state in the Preface. Because 
of this, I hesitate to recommend this 
book, since I believe it missed its mark 
as an introduction. 


J. V. A. Janeri 
MITRE Corporation 
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"Any clod can have the facts, but having opinions is an art." 

Charles McCabe, San Francisco Chronicle 
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Will Tracz, IBM, Federal Sector Division, Mail Drop 0210, Owego, NY 13827 
E-mail tracz@Owgvm0.iinus 1.ibm.com 


What if scientists had found a computer in 1900? 


Over the last few years, I’ve conduct¬ 
ed nanlia dition al surveys regarding tech¬ 
nology and scienceflmrtuding “What is 
the social and scientific impact of a soda- 
can-sized computer with near-infinite'"' 
rriefn tTry-ftft d sp ued? " and “Wl itr a re the 
10 rrfost influentiaTscientists in history?” 
The results of these surveys are present¬ 
ed in greater detail in my book, Comput¬ 
ers and the Imagination (St. Martin’s 
Press, to be published Sept. 1991). 

For a recent survey, I posed the fol¬ 
lowing question to international re¬ 
searchers from different organizations 
and received 60 responses: 

The year is 1900. One IBM PS/2 or sim¬ 
ilar personal computer is given to scien¬ 
tists at Harvard University by an anony¬ 
mous benefactor. With the computer come 
a power source that will allow the unit to 
run for one year, operating manuals, and 
manuals for Fortran programming. 

Assume that the system will run trou¬ 
ble-free for a year. Then, when the power 
source dies, scientists can still analyze 
the hardware. 

What would be the effect on the world 
in the 1900s and on the world today if the 
described scenario actually took place? 

After reading the responses, I was 
most interested in the degree to which 
the opinions of computer professionals 
differed. Some said the computer would 
cause almost no effect, since scientists in 
1900 had little framework in which to 
understand programming concepts. Oth¬ 
ers indicated that a useful program would 
run within three days. Many felt that the 
scientists, in their attempt to understand 
the machine, would destroy it. 

Many scientists suggested that the 
computer would be used at that time to 
generate large tables of functions, much 
like those seen today in the back of 
mathematical handbooks. Some speculat¬ 
ed that the real impact of this event 
would be on the development of the elec¬ 
tronics and computer industries, because 
scientists would have a demonstration of 
what is possible, along with clues for 
achieving these possibilities. Therefore, 
these industries would develop earlier. 


(Some said that our current state of elec¬ 
tronics and computer development would 
have occurred in the late 1950s.) 

The early advent of the computer 
might have slowed research in other ar¬ 
eas, since many of the brightest people 
probably would have gone to Harvard to 
work on the project. As a result, some 
scientists indicated the US might not 
have developed the atomic bomb by the 
end of World War II. Others noted that 
today’s multimillion-dollar mainframes 
with proprietary operating systems 
would not be viewed as the “proper way 
to go” and would never dominate. Fur¬ 
thermore, some indicated that there 
would be one clear standard defined by 
this computer, which everyone would try 
to work toward. 

Here are just some of the many re¬ 
sponses I received. 

Scientific/technical impact 

• Chaos and fractal research acceler¬ 
ates. Computer graphics of fractals in the 
1920s. 

• Power source duplicated, and com¬ 
puter works for longer than a year. 

• Power supply disassembled, render¬ 
ing computer inoperable. 

• Computer-targeted field guns avail¬ 
able in World War I. 

• Computer navigation equipment 
available in World War II. 

• In 1990, we’d use technology that 
won’t be available until 2020-40. 

• Computer used in calculating orbital 
parameters, ballistic tables for artillery, 
and hydrodynamic ship design. 

• Desire to understand the insulation 
materials drives extensive materials tech¬ 
nology investigations. 

• Study of the ferrites in the transform¬ 
ers expands 1900 technologies. 

• Television device development ac¬ 
celerates. 

• Analysis of the manuals’ superior pa¬ 
per leads to competition between paper 
houses and printers. Better paper manu¬ 
als are available today. 

• Patent activity and excitement over the 
corrugated cardboard shipping materials. 


• Within three weeks, K to 5,000 deci¬ 
mal places. 

• Realization that magnetism was in¬ 
volved in the floppy disks leads to iron 
disk players instead of record players and 
the early development of magnetic stor¬ 
age technologies. 


Sociopolitical impact 

• Scientists learn to type. 

• The world population would be high¬ 
er in the 1990s due to medical advances. 

• The first world would be wealthier, 
the second and third worlds hungrier and 
more in debt. 

• Enhanced US prestige, partly due to 
the US placing the first man on moon in 
the 1940s or 1950s. 

• The US government learns of the 
computer’s existence and impounds it. 

• Industrial countries learn of the com¬ 
puter’s existence and steal or copy the 
manuals. 

• Harvard scientists keep the computer 
a secret as they study it, and once the 
power source dies, they publish a multi¬ 
tude of papers. 

• The finely etched circuit boards and 
chips are treated like rare gems, with the 
university’s endowment enriched by the 
display and sale of the artifacts. 

• World War II does not occur, due to 
early development of atomic technology. 

• Rapid technological changes lead to 
severe and irreversible pollution problems. 

• Research in the search for extrater¬ 
restrial intelligence increases as we scan 
the universe for our benefactors. The cre¬ 
ationism paradigm strengthens. 

Predicting a new future as a result of a 
chronological anachronism is not a well- 
defined task, and you may take exception 
to some of the imaginative answers. 
Nonetheless, I am certain that the mis¬ 
placed personal computer would have a 
major impact on humankind. 

Clifford A. Pickover 

IBM Watson Research Center 

Yorktown Heights, NY 
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This conference encompasses the technical aspects of specifying, designing, implementing, and evaluating distributed 
computing systems. In such systems, there are multiple processing resources interconnected to cooperate under system- 
wide control with minimal reliance on centralized procedures, data, or hardware. The location of computing resources may 
span the spectrum from physical adjacency to geographical dispersion. The topics of interest include the following aspects 
of distributed computing systems. 

s 


□ Decentralized and Parallel Computer Architectures 

□ Communication Architectures and Protocols 

□ Protocol Engineering 

□ Distributed Operating Systems 

□ Distributed Databases 

□ Languages, Tools, and Software Engineering 

□ Reliability and Fault Tolerance 

□ Modeling and Performance Evaluation 

□ Distributed Algorithms 

□ Real-Time Issues and Applications 

□ Computer-Supported Cooperative Work 

□ Distributed Artificial Intelligence 


INFORMATION FOR AUTHORS 

Authors are requested to submit six co| 
ies (in English) of their double-space 
typed manuscript (maximum of 20 pages) 
with an abstract to Prof. Urban by Octo¬ 
ber 15, 1991. The conference language 
is English and final papers are restricted 
to eight IEEE model pages. A submission 
letter that indicates which of the confer¬ 
ence areas is most relevant to your pa¬ 
per must accompany the paper. In case 
of multiple authors, an indication of 
which author is responsible for corre¬ 
spondence and preparing the camera- 
ready paper for the proceedings should 
also be included. Authors will be notified 
of acceptance by February 15, 1992 and 
will be given instructions for final prepa¬ 
ration of their papers at that time. Out¬ 
standing papers will be eligible for publi¬ 
cation in IEEE Computer Society/IEEE 
journals. 

Submit papers to: 

Joseph E. Urban 
Dept, of Computer Science and 
Engineering 

Arizona State University 
Tyler Mall-ECG 252 
Tempe, AZ8. 

Tel: (602) 96 ‘ 

Fax: (602) 91 
E-mail: jurba 
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Organizing and Program Committee 


Honorary Chair 

Iwao Toda 

NTT Corporation, Japan 


Tutorials Co-Chairs 

Hideo Miyahara 
Osaka University, Japan 


TUTORIALS 

In addition to papers, proposals for one 
day tutorials are solicited in any of the 
conference areas. Such proposals 
should be submitted to Prof. Wittie by 
October 1, 1991. 

Submit tutorial proposals to: 

Larry D. Wittie 

Dept, of Computer Science 

SUNV at Stony Brook 

Stony Brook, NY 11794-4400, USA 

Tel: (516) 632-8456 

E-mail: lw@sbcs.sunysb.edu 

CONFERENCE LOCATION 

Pacific Convention Plaza, 

Yokohama, Japan 


For more information please contact Ming T. (Mike) Liu or Yutaka Matsushita: 


Ming T. (Mike) Liu 

Dept, of Computer and Information Science 

Ohio State University 

2036 Neil Avenue 

Columbus, OH 43210-1277 

Tel: (614) 292-6552 

Fax: (614) 292-9021 

E-mail: mike.liu@osu.edu 


Yutaka Matsushita 

Dept, of Instrumentation Engineering 

Keio Universtiy 

3-14-1 Hiyoshi, Kohoku-Ku 

Yokohama, Japan 223 

Tel: (045) 563-1141, ext. 3564 

Fax: (045) 562-7625 

E-mail: on@inst.keio.ac.jp 
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Discover 

Parallel 

Processing 


Quadputer ™ 

The Microway Quadputer 
is the world’s most pop¬ 
ular PC Transputer develop¬ 
ment environment. It can be 
purchased with two to four 
Transputers and one to four 
megabytes of RAM per proces¬ 
sor. The Quadputer runs all the 
popular Transputer development 
software, all of which is available 
from Microway. It is compatible with 
our Monoputer™ which provides 1to16 
megabytes of RAM and a single TBOO, 
our Videoputer™ which comes in VGA 
and higher resolution versions and is pow¬ 
ered by a memory mapped pair (T800 and 34010), and our 
Linkputer™ whose cross bar switching network can 
dynamically link up to 32 Transputers. Finally, all Microway 
Transputer products can be used with our Number Smasher- 
860 to provide out-of-this-world numeric performance! 

For more information, please call 508-746-7341. 


NDP Fortran-860, C-860 and C++860 

Microway NDP 860 Compilers make it easy to recompile your 
favorite mainframe, 80386 or PC applicaton for the 80860. The 
resulting code runs on our XTEND-860™ environment under 
DOS, UNIX or XENIX. 


Number 
Smasher® 
860 

The highest 
performance copro¬ 
cessor card to ever 
run ih a PC, Number 
Smasher-860 delivers 
up to, 80 million single 
precision floating point 
operations per second 
at 40 MHz and produces 
over 10 Linkpack mega¬ 
flops. The board comes 
standard with an ISA inter-* 
face, two Transputer Link 
Adaptors that allow it to 
interface with a Microway 
Quadputer or Videoputer, your 
choice of our NDP Fortran, C 
or Pascal for the 80860, plus 8 
megabytes of high speed memory. 


The World Leader in PC Numerics 

Corporate Headquarters, Research Park, Box 79, Kingston, MA 02364 
TEL 508-746-7341 • FAX 508-746-4678 

U.K. - 32 High St., Kingston-Upon-Thames, 081-541-5466 • Italy 02-74.90.749 
Holland 40 836455 • Germany 069-75-2023 • Japan 81 3 222 0544 
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